Why Power BI Desktop blocks macOS and Linux authors
A common situation looks like this: the analysts on a data team work on Macs or Linux workstations, but the reports they need to build still have to land in Power BI. The first thing to confirm is the platform itself. Power BI Desktop, the tool where models and reports are authored, lists Windows as its only desktop platform. Microsoft's minimum requirements call for Windows 10 or Windows Server 2016 or later, .NET 4.7.2 or later, the Microsoft Edge WebView2 runtime and at least 2 GB of available RAM. No macOS or Linux version is listed, so a Mac or Linux workstation cannot run Desktop natively. Check the current requirements on the Power BI Desktop download page before you size a pilot, since the list can change between releases.
That leaves two directions. The first is to move authoring into a browser. Apache Superset builds charts and dashboards on SQL datasets, and Metabase builds questions, dashboards and models through its web interface, so analysts on any operating system can author content against the same database. The trade-off is that DAX measures and Power Query steps do not carry over as-is, so the analysts' skills and the existing model logic both need to be mapped before work starts. The second direction is to keep Power BI and give Windows-dependent users a supported environment. Microsoft states that Power BI Desktop is fully supported on Azure Virtual Desktop and Windows 365, while running it as a virtualized application, such as a published Citrix application, is not supported. Decide which path fits your team, and confirm the chosen virtual desktop product and its licensing with Microsoft and your reseller before rollout.
The decision usually comes down to how much of the existing Power BI model must survive. If most analysts only consume reports, a browser-based self-hosted tool may cover them with less friction. If authors depend on complex DAX and Power Query logic, a supported Windows desktop may be the lower-risk choice during a transition. A practical check is to list the authors, the Desktop-only features they use and the data sources behind each model, then test one representative report on each path. Ask any implementation partner to document which features rebuild in a browser tool and which stay on Windows, so the team does not discover gaps after the migration starts.
What a Mac or Linux authoring environment must provide
Power BI Desktop is Windows-only, so a Mac or Linux team needs a browser-based replacement that covers the same ground: building content, reaching the same data, keeping its own records and controlling who sees what. The six requirements below connect each of those needs to what Apache Superset and Metabase actually document, and to the checks worth running before you commit.
Browser-based authoring surface
Analysts build charts, datasets and dashboards in a web browser, so the operating system on each laptop stops mattering. Superset is built on Flask and React, and Metabase ships as a JAR that serves its interface over HTTP. Check whether your analysts need to write calculations in SQL, use a point-and-click question builder, or both, because the two tools differ in how much of the logic lives in the browser versus the database. Test the authoring flow on a macOS and a Linux machine before rollout.
Connection to the same SQL sources
Power BI reaches data through its own connectors and an import or DirectQuery model. Superset connects to any SQL datastore that has a Python DB-API driver and SQLAlchemy dialect, which means the warehouse you already query stays the single source of truth. Confirm that each source your reports depend on has a maintained driver, that service accounts are read-only, and that query timeouts are set so one dashboard cannot exhaust the warehouse.
Metadata database that survives upgrades
Dashboards, users, permissions and saved questions live in an application database, not in a file on a laptop. Superset stores its metadata in PostgreSQL or MySQL, and Metabase recommends PostgreSQL for production, while its embedded H2 database is meant for demos. Plan backups of this database before every upgrade, since both projects run schema migrations on startup. Confirm which PostgreSQL or MySQL versions your chosen release supports before you provision the server.
Sign-in through your identity provider
Authoring access should follow the same identity lifecycle as the rest of the estate. Superset supports database, LDAP and OAuth authentication through Flask-AppBuilder, including OAuth2 providers such as Google and Azure. Metabase's free edition supports Google sign-in and LDAP, while JWT, OIDC and SAML single sign-on require the Pro or Enterprise plans. Ask which protocol your identity provider offers and whether the required sign-in method is included in the edition you plan to run.
Role-based access to datasets and dashboards
Analysts on Mac and Linux should see only the datasets and dashboards their role allows. Superset can map LDAP or OAuth groups to roles through AUTH_ROLES_MAPPING, so group membership in your directory drives access. On Metabase, row and column level permissions sit in the Pro and Enterprise plans, not the free edition. If a team needs row-level restrictions on the open source build, plan for that gap in the design, not after go-live.
Hosting inside your own network
Because the tools run in your environment, the data path, the session cookies and the secret keys stay inside your network boundary. Superset refuses to start without a user-specified SECRET_KEY and supports rotating it with PREVIOUS_SECRET_KEY. Metabase's air-gapped deployment is listed only on its Enterprise plan. Confirm with the vendor and your network team whether the edition you choose can run without outbound internet access, and document where the metadata database and caching layer are placed.
Which options fit a macOS or Linux team
This table compares where each option is authored, how it is licensed, and whether single sign-on and row-level security are included. Read the Power BI rows as the baseline for keeping Power BI Desktop on Windows through a supported virtual desktop. The main takeaway is that browser-based tools remove the Windows requirement for consumers and most authors, but DAX models must be rebuilt as SQL logic.
| Capability | Apache Superset | Metabase | Power BI on Azure Virtual Desktop or Windows 365 |
|---|---|---|---|
| Where models are authored | Browser, on SQL datasets and virtual datasets | Browser, using questions, models and metrics | Power BI Desktop, Windows only, reached through a supported virtual desktop |
| License model | Apache-2.0, no paid edition | AGPL open source edition, paid Starter, Pro and Enterprise plans | Microsoft Power BI licensing, plus the virtual desktop service |
| Single sign-on | OAuth2 and LDAP through Flask-AppBuilder | Google sign-in and LDAP on free plans, SAML and OIDC on Pro or Enterprise | Microsoft Entra ID sign-in |
| Row-level security | Available in the open-source build, configured per role | Row and column permissions only on Pro and Enterprise plans | Available through DAX roles in the semantic model |
| Model logic format | SQL metrics and datasets, DAX must be rewritten | SQL-based models and metrics, DAX must be rewritten | DAX measures and Power Query steps stay in the .pbix file |
| Mac or Linux authoring | Yes | Yes | No |
| Confirm before deciding | Check your identity provider and role mapping in your environment | Check which plan includes the SSO and permission features you need | Confirm the virtual desktop setup is one Microsoft supports for Power BI Desktop |
How to deploy Superset or Metabase for browser authoring
This sequence takes a browser-based BI deployment from an empty server to a production instance that analysts on macOS or Linux can author in, with every component kept inside your own network.
Confirm the hosting boundary and components
Your infrastructure or platform team decides where the servers, databases and network paths will live, and confirms that the browser, the BI application, its metadata database and the data sources all sit inside your own network or private cloud accounts. For Superset, list the four components from the architecture documentation: the Flask and React application, a metadata database, an optional caching layer and optional Celery workers. For Metabase, list the application and the database it will use. Done when the architecture diagram is signed off and shows no external SaaS dependency for authentication, storage or telemetry you have not approved.
Provision the metadata database
Your database administrator creates a dedicated PostgreSQL or MySQL instance for the BI application's own metadata, separate from the analytical data sources analysts will query. Superset's documentation lists PostgreSQL 10 to 17 and MySQL 5.7 and 8.x as supported metadata versions, and Metabase recommends PostgreSQL for production and supports MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4. Do not use the SQLite default of Superset's Quickstart or PyPI installs, which the architecture documentation does not recommend for production. Confirm backups are scheduled before the first start. Done when you can connect with a test client, the backup job has produced one restorable copy, and the credentials sit in your secrets store.
Set the secret key and configuration
Your platform engineer writes the configuration file, for Superset typically
superset_config.py, and sets a user-specified SECRET_KEY, which Superset requires before it will start. Store the key in your secrets manager and inject it at runtime rather than committing it to Git. Record the procedure for rotation using PREVIOUS_SECRET_KEY so a future rotation does not lock out existing sessions. For Metabase, set the application database connection values through environment variables as described in its configuration documentation. Done when the application starts cleanly against the metadata database and the secret is absent from the image and repository.Connect sign-in through OAuth or LDAP
Your identity team connects the BI application to your directory. Superset is built on Flask-AppBuilder and supports OAuth2 providers such as Google and Azure, custom OAuth2 servers using the code flow, and LDAP. Metabase's open source and Starter plans support Google sign-in and LDAP, while JWT, OIDC, SAML and SCIM require Pro or Enterprise, so confirm which protocol your identity provider needs before you choose a plan. Test with a non-administrator account first. Done when a test user signs in through the chosen path, local fallback accounts are documented, and sign-in events appear in your logs.
Map directory groups to BI roles
Your BI administrator maps directory groups to application roles so that browser authoring rights follow group membership. In Superset, set AUTH_ROLES_MAPPING in the configuration to translate LDAP or OAuth group names into Superset roles, and keep the mapping in version control. In Metabase, configure group sync on the plan that includes it, and confirm that the authoring group can create questions and dashboards while read-only groups cannot. Done when a test account from each group sees exactly the expected menus and data sources, and the mapping file has been reviewed by the owner of the directory.
Decide on caching and Celery workers
Your platform team decides whether alerts and reports, async queries and dashboard thumbnails are required. The architecture documentation states that these features need the caching layer and the worker components, and most installations use Redis and Celery for them. If analysts only author charts in the browser, you may defer these components, but record that decision and the features it turns off. If you enable them, deploy the cache and workers as separate services, size them with your load testing, and confirm the scheduler runs on exactly one beat process. Done when a scheduled test report runs and an async query returns, both within your own network.
Move Metabase off the embedded H2 database
If you deploy Metabase, your administrator replaces the embedded H2 application database, which ships for demos, with PostgreSQL or MySQL before any analyst uses the instance. Metabase documents a one-time load-from-h2 command for this move, and it must run with the same Metabase version that last updated the H2 file. Take a backup of the H2 file first and keep it until the migrated instance is verified. Done when the instance reads its questions, dashboards and users from the new database and the H2 file is archived under your retention policy.
Validate, back up and document the release
Your team runs the first database initialization and checks the result in a staging copy before production. For Superset, follow the upgrade documentation: back up the metadata database, run superset db upgrade and superset init, and review UPDATING.md for breaking changes. For Metabase, take an application database backup before each upgrade and check the version support page for end-of-life dates. Record the version, configuration sources, backup location and owners in your runbook. Done when a restore test from the backup succeeds and the runbook is approved by the platform owner.
Questions teams ask before moving authoring off Windows
What does it cost in effort to move Power BI authoring off Windows?
The effort depends mostly on how much of your Power BI estate is authoring logic rather than consumption. Costs fall into three groups: the internal time spent inventorying reports, semantic models and DAX measures; the rebuild of those measures as SQL datasets, metrics or Metabase models; and the platform work to host Superset or Metabase with a production metadata database, caching and authentication. Costs rise with the number of DAX measures that use calculation context, the number of Power Query transformations that must move upstream, and the number of data sources. Ask any partner for a quote built from a written scope that lists these three groups separately, and confirm whether the quote includes the first-year upgrade and support work.
How long does a pilot take, and what sets the timeline?
We do not publish a standard pilot duration because the timeline depends on your environment. The factors that set it are the number of reports in the pilot, whether their DAX logic can be expressed as SQL, how many data sources need access from the new host, and how quickly your identity team can register an OAuth or LDAP client. Approvals for a new internal service, change windows and security review usually take longer than the build itself. Ask for a timeline that lists the pilot reports, the data sources and the approval steps as separate milestones, and check what counts as acceptance for each report.
Can our team run Superset or Metabase without outside help?
A capable team can run either tool in-house, but the requirement is ongoing operations rather than initial setup. Someone needs to own the container or Kubernetes deployment, the PostgreSQL or MySQL metadata database, backups, and upgrades. Superset upgrades call for a metadata backup, superset db upgrade, superset init, a staging test and a review of UPDATING.md. Metabase upgrades run application database migrations automatically, so backups before each step and release-by-release upgrades from older versions matter. Skills most often missing are SQL modeling, identity integration and secure secret handling. Decide early which of these you will staff internally and which you will contract as a retainer.
What do our identity and data teams need to provide?
Identity and data teams are on the critical path. The identity team provides an OAuth2 client, typically for Google or Azure, or an LDAP bind account, and decides how groups map to roles through AUTH_ROLES_MAPPING in Superset or group sync in Metabase. The data team provides read-only database accounts, network paths from the new host, and the schema documentation needed to define datasets or models. Both teams should confirm how row-level access is enforced, because the Power BI model may rely on RLS roles that must be rebuilt. Agree on who approves service accounts and secret storage before the pilot starts, not during it.
Do we need Metabase Starter or Pro for SSO and row-level permissions?
Yes, if you need row-level or column-level permissions or the full SSO list. According to the Metabase pricing page, row and column level permissions and SSO are included only in the Pro and Enterprise plans, not in Open Source or Starter. The Open Source and Starter plans support Google sign-in and LDAP, while JWT, OIDC, SAML and SCIM provisioning require Pro or Enterprise, per Metabase's people and groups documentation. Starter is listed at $100 per month, or $90 per month billed yearly, with the first 5 users included, and Pro at $575 per month, or $517.50 per month billed yearly, with the first 10 users included. Confirm current prices on the pricing page before budgeting, because plan terms can change.
Can Power BI Desktop run on Azure Virtual Desktop?
Yes. Microsoft Learn states that Power BI Desktop is fully supported on Azure Virtual Desktop and Windows 365. Running it as a virtualized application, such as a published Citrix application, and in other virtual desktop environments is not supported. Azure Virtual Desktop is a practical option if Power BI stays and macOS or Linux users only need occasional access to Windows authoring. Costs come from the session host compute, storage and Windows licensing, which recur monthly, and from the setup of images and user profiles, which is one-time. Confirm the licensing terms for your user type with Microsoft before committing.
Which should we choose: browser authoring in Superset or Metabase?
Choose Superset when your analysts write SQL and need broad chart types, a semantic layer built from datasets and metrics, and a deeper control over the stack. Choose Metabase when business users need a guided question builder, and when the Open Source edition covers your sign-in and permission needs. Both run in a browser, so macOS and Linux users need no desktop client for authoring. The decision turns on who builds the models, which permissions you require, and how much SQL your team will own after the migration.
Will Superset or Metabase keep report exports and embedded content working?
Not automatically. Microsoft lists limits on .pbix downloads, including Direct Lake models, models with incremental refresh and data models larger than 50 GB, so inventory these before planning the export. Visuals and DAX measures do not transfer as files and must be rebuilt as Superset datasets with SQL metrics or as Metabase questions and models. Embedded Power BI content needs a new tenant isolation design in Superset guest tokens or Metabase embedding, sized to your plan. Ask your partner to produce a per-report list showing what rebuilds cleanly and what needs redesign.
How to keep Power BI Desktop on a supported Windows environment
If Power BI stays, the Microsoft-supported route for macOS or Linux users is a Windows desktop that you reach remotely, and the only virtualized setups Microsoft names as fully supported are Azure Virtual Desktop and Windows 365. Power BI Desktop run as a published Citrix application or in other virtual desktop environments is not supported, so a team that already delivers Power BI through Citrix should plan a move of its authoring sessions before relying on it. Confirm the current support statement in the Microsoft Learn download page for Power BI Desktop and in your Azure Virtual Desktop or Windows 365 documentation, because support statements change between releases.
The minimum requirements Microsoft lists for the session host are Windows 10 or Windows Server 2016 or later, .NET 4.7.2 or later, the Microsoft Edge WebView2 runtime, and at least 2 GB of available RAM. Treat 2 GB as a floor, not a sizing target: the size of your semantic models, the number of concurrent authors and any other applications on the same session host will determine the memory you actually need. Check the requirements against the Windows image you plan to publish, confirm them with Microsoft before rollout, and record the version of Power BI Desktop in use, since authoring files saved by a newer build may not open in an older one.
The decision to make is whether the Windows session stays the authoring environment for the long term. Every author on macOS or Linux will need a licensed Windows desktop or session, plus the Azure or Windows 365 subscription that hosts it, and those costs recur for as long as Power BI remains. Ask Microsoft or your reseller to confirm the license terms for remote Windows access for your users, and compare that recurring cost with the one-time effort of rebuilding reports in a browser-based tool, as covered in the migration pages. Keep the session images, the Power BI Desktop version and the data source connections documented so that a later move, if you make one, starts from a known state.
Evidence that the browser-based setup meets your controls
Auditors and security teams rarely accept a tool on its description alone. The items below are the records that show what runs, who can sign in, what changed and who still has access. DeployOpen prepares this evidence inside your environment, but independent auditors and certification bodies decide whether it meets your obligations.
Architecture and component inventory
Document each component of the Superset or Metabase deployment: the web application, the metadata database, the optional caching layer and any Celery worker and beat processes. For each one, record the version, host, network path and the data it touches. Alerts, reports and async queries depend on the caching and worker components, so an inventory that omits them will misstate the attack surface. Confirm which datastores the browser tool can query.
Authentication and role mapping configuration
Keep the configuration files that set how users sign in and which roles they receive. For Superset, this means the settings for database, LDAP or OAuth2 authentication and the AUTH_ROLES_MAPPING entries that tie directory groups to roles. For Metabase, it means the SSO and group settings, which depend on the plan you choose. Store these under version control with change approval so an auditor can trace every role grant to a reviewed change.
Secret key and rotation records
Superset will not start without a user-specified SECRET_KEY, and the configuration docs describe rotating it with PREVIOUS_SECRET_KEY. Record where the key is stored, who can read it, the date of each rotation and the procedure used. Confirm that the key is not committed to the repository that holds your configuration files, since those files are the ones auditors will read.
Upgrade records with pre-change backups
Each upgrade should produce a dated record: the version moved from and to, the release notes or UPDATING.md entries reviewed, the staging test result and a verified backup of the metadata database taken before running superset db upgrade and superset init. For Metabase, the record should show the application database backup taken before migrations run, and the node count during any major upgrade. An auditor will ask whether the backup was restorable, so include the restore test.
Metabase version support schedule
Pin the release you choose and write down its support window. Metabase LTS versions receive support for 14 months, and non-LTS releases usually reach end of life after 2 months. Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027. Record the planned upgrade date before that end-of-life date, and confirm the current schedule on the vendor version support page, since it changes as new releases ship.
Periodic access reviews
Export the user list, group memberships and role assignments from Superset or Metabase at a set interval, then have the data owner confirm each entry. Remove accounts for leavers and contractors, and check that administrator rights are limited to named people. Retain each signed review with its date. On Metabase's free edition, row and column level permissions are not available, so reviews there cover who can see which collections rather than which rows.
How DeployOpen deploys BI under a platform constraint
DeployOpen plans and implements self-hosted open-source BI inside your own cloud accounts, data centers or air-gapped networks, so analysts on macOS or Linux get a browser-based path that does not depend on Power BI Desktop. Each engagement starts from a written scope that names the platform, the data sources and the Windows-only work that stays where it is.
How we scope
- Inventory the Power BI Desktop authoring work by team, report and data source before any build starts.
- Name which reports move to Apache Superset or Metabase and which stay on a Windows desktop or virtual desktop.
- Record the identity provider, network zones and hosting location the written scope must respect.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Deploy Superset or Metabase with PostgreSQL or MySQL as the application database, not the embedded default.
- Configure SECRET_KEY handling, sign-in through LDAP or OAuth, and role mapping for each analyst group.
- Rebuild the chosen datasets, metrics and dashboards against your source databases in a staging environment.
- Test authoring, sharing and permissions on macOS and Linux browsers before any user is moved.
How we hand over
- Document the architecture, configuration keys, backup steps and upgrade runbook for your own operators.
- Provide the migration record that maps each Power BI artifact to its replacement or retained Windows path.
- Deliver a rollback plan and a checklist for upgrades that follow the vendor's breaking-change notes.
- Walk through administration with the people who will own the platform after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade planning covers backups of the application database, staging tests and release-by-release moves.
- Security testing of the BI platform and its connections can be scoped separately under the same written terms.
- Quotes follow from the written scope, so ask for the cost components and recurring items to be listed.
