Open-source alternative to Power BI Embedded

Open-source alternative to Power BI Embedded for product teams

A product team that embeds Power BI reports for its own customers pays for capacity that handles both rendering and tenant separation. Apache Superset's embedded SDK, with guest tokens and row-level security rules, and Metabase's embedding options by plan can replace the viewing layer, but the tenant isolation and capacity model have to be rebuilt by your team or your implementation partner. This page covers the embedded delivery layer only: how end customers see dashboards inside your product. It does not cover how analysts author reports in Power BI Desktop or the Power BI service, which is addressed on the sibling migration pages.

Start by mapping what Power BI Embedded currently enforces for you. In Superset, the embedding flow is built on the @superset-ui/embedded-sdk package with the EMBEDDED_SUPERSET feature flag set to True, and your host application's server requests guest tokens from /api/v1/security/guest_token/ using a service account. Row-level security rules attached to each guest token decide which rows a viewer can see, so every tenant boundary you previously relied on must be written as an explicit rule and tested per tenant. Confirm the exact rule syntax and token lifetime behavior against the current Superset embedding documentation at Apache Superset: Embedding before you commit to a design.

Metabase's embedding is gated by plan, so the cost of each option depends on which controls your tenants need. Confirm with Metabase which embedding, SSO and row-level permission features are included in the plan you would buy, because the open source edition lacks row and column level permissions. Plan a tenant isolation test suite, a service account for token issuance and a capacity model based on your own session counts, since no vendor figure can stand in for your load. The reader should ask any integrator for a written scope covering tenant isolation tests, token issuance design and capacity testing before work starts.

Which embedded capability maps to which open-source option

This table maps the main Power BI Embedded capabilities to Apache Superset guest tokens, Metabase embedding by plan and the host-application code you would write. Read the Metabase column as a checklist: confirm each feature against the plan you intend to buy before you commit.

Capability	Apache Superset	Metabase	Host application responsibility
App-owns-data embedding	Host server requests a guest token from the security API using a service account, then the browser loads the dashboard with the embedded SDK	Signed embedding with a secret key or JWT-based embedding, where the host signs a token for each viewer; confirm which option your plan includes	Your server issues short-lived tokens after authenticating the end user in your own app
Service principal or master user access	Service account with the Gamma or embedded role, scoped to the dashboards it may embed	A signing key or API key held server-side; no shared master login should reach the browser	Store the service credential in a secrets manager and rotate it
Row-level security per tenant	Row-level security rules attached to each guest token restrict the rows a viewer sees	Row and column level permissions are listed as Pro or Enterprise features on the pricing page; confirm embedded use cases on your plan	Enforce tenant filters in the database role or view as a second layer, so a missing rule cannot expose other tenants
Tenant isolation at the data layer	Depends on the dataset: RLS rules in tokens plus database-level views or roles	Multi-tenant data segregation is listed only on Pro and Enterprise; confirm it covers your model	Design tenant keys and test cross-tenant access before go-live, since no direct equivalent to Power BI capacity isolation exists
Capacity-based scaling	No licence-tied capacity unit; scale by adding Superset web workers, a caching layer and Celery workers	No capacity SKU; scale the Metabase application and its database, and confirm cluster behavior in the upgrade docs	Size infrastructure against concurrent viewers and query load, which you measure yourself; there is no direct Power BI capacity equivalent
White-label styling	Theming through Superset configuration and the host page around the embedded frame; confirm options for your version	Confirm branding and custom styling options on each plan before assuming parity	Control the surrounding UI and sign-in screens in your own application
Sign-in handled by the host app	Host authenticates the user and maps the viewer to a token; Superset's own login is not shown to embedded viewers	Host authenticates the user; embedded viewers should not need a separate Metabase account, which you should verify on your plan	Own the session lifecycle, token expiry and logout behavior
Embedding licence cost	Apache-2.0 with no paid edition; cost is infrastructure, implementation and support	Free Open Source edition for self-hosting; paid plans add features such as SSO and row-level permissions, and Enterprise is quoted	Ask any vendor or partner for a written quote covering scope, support and upgrades

Choosing Superset or Metabase by tenant model and team skills

When one application serves many customers from shared infrastructure, the central question is how each tenant sees only its own rows. Superset's embedding path is built around a host application that requests a guest token from /api/v1/security/guest_token/ using a service account, and that request can carry row-level security rules scoped to the viewer. Your backend therefore decides the tenant filter on every token, which keeps the isolation logic in code you already own. Metabase handles this differently: row and column level permissions, multi-tenant data segregation and usage analytics are included only on the Pro and Enterprise plans, so a free deployment means building that boundary yourself.

Superset guest tokens: The host server requests a token per viewer and attaches the tenant's RLS clause, so the embedded dashboard never receives unscoped credentials.
Metabase plan gating: Multi-tenant segregation and per-plan row-level permissions sit behind paid tiers, so budget them before you commit to the embedding design.
Shared metadata store: Both tools keep application state in one database, so tenant data separation depends on your query rules and access tests, not on the tool alone.
Test coverage: Write automated checks that request tokens for two tenants and confirm each receives only its own rows.

Confirm with each vendor's current documentation which isolation features your target plan includes before you finalize the architecture.

A single-tenant or partner-facing deployment gives each customer or partner its own instance, or a small set of instances with a fixed user base. Isolation then comes from the deployment boundary rather than from row filters on shared data, which often makes the operating cost the larger concern. Superset still suits this model when you want guest-token embedding inside a partner portal, while Metabase suits teams whose partners mainly need sign-in and dashboards without custom embedding logic. Plan the number of instances up front, because each one carries its own metadata database, upgrades and backups.

Instance count: Each customer instance repeats the database, application, caching and worker footprint described in the architecture documentation, so cost grows with the number of tenants.
Upgrade coordination: Superset upgrades require a metadata database backup, superset db upgrade and superset init, and staging tests, which you must repeat per instance.
Metabase upgrade rules: Metabase runs application database migrations automatically and recommends a backup first, and upgrades from versions older than 40 should proceed release by release.
Partner sign-in: Confirm whether SSO or SAML for partner users is needed, since Metabase reserves SAML and SCIM for Pro or Enterprise.

Ask your partners and any contract for their identity requirements before you settle on the instance count.

Teams that model data in SQL and want analysts to define metrics against curated datasets tend to fit Superset well. Superset connects to any SQL datastore with a Python DB-API driver and SQLAlchemy dialect, and its charts sit on datasets that can be defined and reviewed in SQL. Engineers who already maintain warehouse views will recognize the workflow, and the embedded dashboards inherit that model directly. The tradeoff is that Superset expects people comfortable with SQL and its configuration files, so the product owners who need to build their own charts may need more support.

Dataset ownership: Analysts and data engineers define datasets, metrics and joins, which keeps business logic in version-controlled SQL.
Driver management: Each database needs its Python driver installed in the Superset image, so add that to your build pipeline.
Authentication setup: Superset supports database, LDAP and OAuth authentication through Flask-AppBuilder and maps groups to roles with AUTH_ROLES_MAPPING.
Skill check: Confirm that at least two people can troubleshoot the metadata database, Celery workers and Redis caching in production.

Run a pilot with your analysts before committing, because the day-to-day effort depends on who writes the datasets.

Apache Superset, Metabase and host-built isolation compared

Each option answers the same question from a different angle: how a viewer from your customer base sees only their own data inside a report you host. Superset gives you guest tokens with row-level rules, Metabase gates embedding and row-level permissions by plan, and a host-built viewer puts all tenant logic in your own code. The right choice depends on which of these controls you can own and which you need to buy.

Apache Superset guest tokens

Superset embeds dashboards through the @superset-ui/embedded-sdk package, which requires the EMBEDDED_SUPERSET feature flag set to True. Your server requests a guest token from /api/v1/security/guest_token/ using a service account, and that request can carry row-level security rules that limit what each embedded viewer sees. Confirm that your host server, not the browser, creates these tokens, and test that one tenant's token cannot read another tenant's rows. The license is Apache-2.0 with no paid edition, so the cost is the infrastructure and the engineering time you spend on tenant rules.

Metabase embedding by plan

Metabase embedding depends on the plan you buy. The free Open Source edition is self-hosted with unlimited users and dashboards, but SSO and row and column level permissions sit in the paid Pro and Enterprise plans, and multi-tenant data segregation is also limited to those tiers. Before you design tenant isolation around Metabase, confirm with Metabase which embedding features, sign-in methods and permission controls are included in the plan you intend to run, and get that in writing with the price for your user count. Only Enterprise offers air-gapped deployment.

Host-built tenant viewer

A custom viewer is a web application your team or DeployOpen builds, which reads data from a reporting database and renders charts with a library you choose. Your application code enforces tenant isolation through query scoping, database views or row policies, and the BI engine does not hold permission logic. This gives full control over isolation and branding, but every control is your responsibility: authorization, audit logging, query limits and security testing. Plan for ongoing ownership of the viewer, and ask whether the isolation design will be tested before release.

Tenant isolation ownership

Whichever option you choose, the isolation boundary has to be designed, not inherited from Power BI Embedded capacity. Map every tenant identifier to a rule in the database or the BI layer, decide where the signed token or session is created, and document who can change those rules. Superset and Metabase can enforce row rules, but the mapping from your customer identity to the rule value stays in your code. Test cross-tenant reads, expired tokens and forged parameters before any customer sees the feature.

Operating the embedding stack

Superset embedding relies on its metadata database, and when you use alerts, async queries or thumbnails it also depends on Redis and Celery workers, so an embedded dashboard is only as available as those parts. Metabase runs its application database migrations automatically on upgrade, so embedded reports need a tested upgrade path and a database backup first. Ask who patches these components, who carries the on-call duty for customer-facing outages and how the vendor or your partner supports upgrades to the next release.

How guest tokens and row-level security replace Power BI Embedded isolation

Power BI Embedded handled identity and data access through Microsoft's service, but with Superset the host application must make those decisions itself. Your server authenticates the end user, works out which tenant and rows that user may see, and then calls the /api/v1/security/guest_token/ endpoint with a service account to request a guest token. The embedded SDK in your front end (@superset-ui/embedded-sdk) only receives that token. The EMBEDDED_SUPERSET feature flag must be set to True before any of this works, and the RLS rules travel inside the guest token request, so the restriction is applied on the Superset side rather than in your page code.

The most common failure is trusting a tenant identifier that arrives from the browser. If the front end sends a tenant_id or a dashboard filter value and your server passes it straight into the RLS clause, any signed-in customer can change that value and read another customer's rows. The tenant should come from the server-side session or the verified token claims, and the RLS clause should be built from that value only. Keep the service account's privileges narrow, and confirm with the Superset embedding documentation how guest token lifetimes and resource scopes are configured in the version you deploy.

Before any customer sees data, test in staging with at least two tenant accounts and a user who should see no rows at all. Confirm that every dashboard and chart on the embedded dashboard applies the rule, including saved charts and native filters that could bypass it, and that a manually edited token or altered filter parameter returns nothing. Record the results as evidence for your own access review. Ask your security team to test the endpoint directly, outside the front end, because that is the path an attacker would use.

Running embedded analytics beside the rest of a Power BI estate

Most teams that embed analytics for customers still keep Power BI for employees during the transition. The cards below cover the decisions that connect the two paths: identity, data sources, metric definitions and the operational load of running two BI stacks at once.

Separate identity paths

Employees sign in to Power BI through Microsoft Entra ID, while embedded customers should never reach an employee sign-in flow. In Superset, the host application's server requests a guest token from /api/v1/security/guest_token/ using a service account, so the customer never authenticates to Superset directly. Confirm which identity provider your internal users will keep and how group membership maps to Superset roles through AUTH_ROLES_MAPPING.

Keep tenant rules out of the shared stack

Internal Power BI workspaces and customer embeds often read the same warehouse. Row-level security rules attached to guest token requests restrict what each embedded viewer sees, but internal analysts working in the workspace are not bound by them. Decide whether embedded content reads from a separate schema, a separate database user or a separate Superset database connection, and test that a guest token for one tenant cannot return another tenant's rows.

Share the warehouse, not the semantic model

Power BI semantic models hold DAX measures that internal reports depend on. Superset datasets and Metabase models are separate objects, so the two stacks will hold separate copies of the same logic unless you choose a single home for it. A practical starting point is to define core metrics as SQL in the warehouse or a dbt-style layer, then point both stacks at those views. Confirm which team owns each metric before cutover.

Avoid two sources of truth

Two dashboards showing different revenue or active-user totals create support tickets and audit questions. Maintain a single metric register that lists each definition, its owner and the Power BI measure or Superset metric that implements it. Review the register whenever a measure changes, and compare outputs for a fixed reporting period in both stacks before retiring the old measure.

Plan for two upgrade cadences

Power BI updates arrive on Microsoft's service schedule, while a self-hosted Superset instance changes only when your team upgrades it. Superset upgrades call for a metadata database backup, superset db upgrade and superset init, with testing in staging first and a check of UPDATING.md for breaking changes. Assign an owner for the open-source stack's patching so the embedded layer does not fall behind the internal one.

Size the operational load

Running an embedded layer adds components to operate: the Superset web application, a PostgreSQL or MySQL metadata database, and, for alerts, reports and async queries, a caching layer and Celery workers. Ask your implementation partner to document which components serve customers and which serve employees, so an incident in one path is scoped correctly. Confirm the effort and cost in a written quote rather than assuming it from licensing.

Migrating embedded reports and tenant rules to self-hosted BI

This sequence moves each embedded Power BI report and its tenant rules into a self-hosted BI tool, with isolation proven in staging before any customer is switched over. The result is an inventory, rebuilt datasets and metrics, a guest token issuer, and a tenant-by-tenant cutover record.

Inventory embedded reports and tenant rules
Your product team and the engineers who own the embed code list every Power BI report embedded in the product, the workspace and semantic model behind each one, and the customers or tenants who see it. For each report, record where row-level security is defined (in the DAX model roles, in the application layer, or in both), which filters are applied from the signed-in user, and which tenants have custom views. The step is done when every embedded report maps to a tenant rule and an owner, and the list is reviewed by someone outside the team that built the embed.
Export model definitions and identify blocked downloads
Workspace Contributors download each report and semantic model as a .pbix file where Microsoft allows it. Models with incremental refresh, Direct Lake models and models larger than 50 GB cannot be downloaded with their data, so mark those as rebuild items at this stage. Keep the exported .pbix files and a copy of the DAX measures and role definitions in version control so the logic survives the migration. The step is done when every report has either an exported file or a rebuild flag, and the rebuild list is agreed with the data owners.
Rebuild measures as SQL datasets and metrics
Data engineers recreate each DAX measure as a SQL expression on a Superset dataset or as a Metabase model with its metric definitions, reading from the same warehouse tables the Power BI model used. Where the source is a rebuild item, they connect directly to the database rather than to an exported model. Each rebuilt metric is compared with the Power BI output for a sample of dates and tenants, and any difference is logged with its cause. The step is done when the rebuilt figures match the source for the agreed test set, or every gap has a documented decision.
Implement guest token issuance
Your application's server requests guest tokens from Superset's /api/v1/security/guest_token/ endpoint, using a service account, after it has confirmed the signed-in user's tenant. The Superset embedding feature needs the EMBEDDED_SUPERSET feature flag set to True, and the front end loads dashboards with the @superset-ui/embedded-sdk package. Each token carries row-level security rules that restrict the rows the viewer can see to their tenant. Metabase equivalents depend on the plan, so confirm the signed embedding options available for your tier before choosing the tool. The step is done when a test user from one tenant cannot retrieve data for another tenant through the embed or the API.
Run tenant isolation tests in staging
The security or QA team runs a scripted set of cross-tenant tests against a staging copy of the BI stack. They attempt to read other tenants' dashboards, change filters in the browser, replay tokens, request charts with altered parameters, and query the metadata database directly to confirm that row-level rules are enforced in the database layer and not only in the interface. They also check that the service account has no broader rights than the token issuer needs. Record each test, the expected result and the actual result. The step is done when every test passes or has a signed-off fix and a retest, and the results are retained as evidence for customers and auditors.
Harden the stack and confirm operations
Operations engineers configure the metadata database (PostgreSQL or MySQL, not the SQLite default), a user-specified SECRET_KEY, backups of the metadata database, and any caching or worker components the embedded features need. They confirm the upgrade path, including a staging test and the release notes in UPDATING.md for Superset, or the migration notes for Metabase. The step is done when the staging environment can be rebuilt from configuration files and a restore from backup has been tested.
Cut over tenant by tenant
Product and customer success teams move tenants in small groups, starting with an internal or pilot tenant. For each group, the team switches the embed to the new endpoint, confirms that figures match the Power BI view for an agreed set of reports, and keeps the Power BI embed available as a fallback until the group signs off. Each cutover is recorded with the tenant, the date, the test results and any customer-facing differences in layout or export. The step is done when every tenant is on the new stack and the Power BI embed has been retired for that tenant, with the decommissioning record kept.

What do teams ask before replacing Power BI Embedded?

What drives the cost of replacing Power BI Embedded with self-hosted tools?

Cost follows the components you must staff and run: engineering to rebuild the embedding flow, infrastructure for the BI application and its metadata database, support and upgrade work, and testing of tenant isolation. Software licensing is only one line. Apache Superset is released under Apache-2.0 with no paid edition, so its recurring cost is mostly infrastructure and people. Metabase's Open Source edition is free to self-host, but embedding features that depend on plan level must be priced separately. Ask any provider for a quote that splits one-time build work from recurring operations, and that lists who is paid for each item.

How long does an embedded analytics replacement usually take?

The timeline depends on how many embedded reports you have, how many data sources sit behind them, how complex your row-level rules are, and how much of the host application's authentication must change. Each of these drives effort up or down. No duration is supplied here, so ask for a timeline in the written scope that lists phases such as environment setup, data source connection, guest token or embedding flow, tenant isolation testing, and staged cutover. Check that the scope names what is out of scope.

Can our in-house engineers rebuild embedding ourselves?

Often yes, if your team already runs production web services and has experience with identity, databases and secrets handling. Superset's embedding flow relies on a host application server that requests guest tokens from the /api/v1/security/guest_token/ endpoint using a service account, and the SDK must be enabled with the EMBEDDED_SUPERSET feature flag. The harder part is proving that tenants cannot see each other's data, which needs independent testing and documented evidence. Many teams split the work: internal staff own the host application, while an outside team handles hardening and testing.

What must our host application provide to embed Superset dashboards?

Your host application needs a server-side component that authenticates its own users, calls the guest token endpoint with a service account, and passes a token to the browser, where the @superset-ui/embedded-sdk package mounts the dashboard. The guest token request can include row-level security rules, so the server must derive those rules from the tenant the user belongs to, never from client input. You also need a metadata database that Superset supports, and a SECRET_KEY set before startup. Confirm how your tenant model maps to these rules before building.

How do Metabase plan features affect embedding?

Metabase's free Open Source edition is self-hosted with unlimited users and dashboards, but according to its pricing page, row and column level permissions, SSO and multi-tenant data segregation are included only in the Pro and Enterprise plans, not in Open Source or Starter. Pro is listed at $575 per month, or $517.50 per month billed yearly, with the first 10 users included and $12 per additional user per month. Enterprise is priced by quote, starting at $20,000 per year. Confirm current prices on the pricing page, because tenant isolation needs will decide which plan you require.

What should we ask for in a written scope for this work?

Ask for a scope that names each embedded report, each data source, the authentication flow, the tenant isolation design and its test method, and the environments to be delivered. Require a list of deliverables such as configuration, runbooks, backup procedures and upgrade steps, and confirm how breaking changes between Superset releases are handled, using the upgrade guide and UPDATING.md. Also ask who owns the service account credentials and the Redis and Celery components if alerts or async queries are needed. Scope, deliverables and timelines should be agreed in writing before work starts.

What upgrade cadence should we plan for after go-live?

Plan for regular upgrades, because the platform keeps moving. Apache Superset 6.0.0 was published on December 18, 2025 and 6.1.0 on May 13, 2026, according to PyPI. Before each upgrade, back up the metadata database, run superset db upgrade and superset init, and test in staging first. Metabase LTS versions are supported for 14 months, and Metabase 64 is an LTS release with end of life on 1 December 2027, according to its version support page. Ask any provider how upgrades, testing and rollback are priced and scheduled, either as a fixed project or a retainer.

Testing tenant isolation before customers see data

This sequence proves that one customer's embedded dashboards cannot show another customer's rows, that guest tokens expire and cannot be replayed, and that the signing secrets are handled correctly before any production traffic reaches the embed. It ends with a written test record that your own team and any independent assessor can review.

Define the tenant model and test scope
Write down how each customer maps to a tenant identifier, which datasets and dashboards are embedded, and which Superset roles and row-level security rules apply to each tenant. Agree the scope in writing with DeployOpen or your internal security team, including the staging environment, the host application and the Superset API endpoints that issue guest tokens. The output is a scope document and a tenant-to-rule matrix that every later test checks against.
Verify the embedding configuration baseline
Confirm in the staging deployment that the EMBEDDED_SUPERSET feature flag is set as intended and that the guest token endpoint is reachable only from the host application's server, not from browsers. Check that the embedded dashboards are the only content exposed to guest tokens and that the service account has no more permissions than the embedding requires. The output is a configuration record signed off by the platform owner.
Test cross-tenant data leakage
Request guest tokens for two or more test tenants, load each embedded dashboard, and compare the rows, filters and cached results each viewer receives. Repeat with the same dashboard open in parallel sessions and after switching tenants in one browser, because cached query results and shared filter state are common sources of leakage. The check is complete when no test tenant can see another tenant's identifiers or values in any chart, tooltip, export or drill-through.
Attempt row-level security bypass
Try to alter the tenant filter from the browser by editing embedded filter parameters, reusing a token issued for another tenant, and requesting chart data through the Superset API with a guest token. Also test whether a viewer can reach datasets, SQL Lab or chart endpoints that the guest token does not list. The step closes when every bypass attempt is denied and each denied request is recorded in the test log with its response.
Test guest token expiry and replay
Issue a guest token, let it expire, and confirm that Superset rejects it. Then capture a valid token and try to reuse it after expiry, from a different session, and from a different network path. Confirm that the host application requests a new token for each embed session rather than storing one long-lived token. The output is a pass or fail result for each expiry case, with the configured lifetime recorded alongside it.
Check secret handling for SECRET_KEY and the service account
Verify that SECRET_KEY is supplied from a secrets store or environment variable rather than from a committed configuration file, and that it is not written to logs, container images or the Superset UI. Confirm that the service account credentials used by the host application are stored in the host's secret manager, have their own rotation procedure, and cannot sign in to the Superset user interface. Where a key rotation is planned, test PREVIOUS_SECRET_KEY on staging before production. The output is a secret inventory with owners and rotation dates set by your team.
Record results and retest after each change
Consolidate the findings into a test report that lists each scenario, the evidence, the defects found, their fixes and the retest result. Repeat the affected tests after any change to the embed configuration, row-level security rules, Superset version or host application. DeployOpen runs security testing of applications and APIs and can deliver this report as evidence for your own assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.

How DeployOpen scopes and delivers embedded analytics replacement

DeployOpen plans, implements and hands over embedded analytics for Power BI Embedded replacements inside your own cloud accounts, data centers or air-gapped networks. Engagements start with a written scope that covers the embedding model, tenant isolation and the platforms you will run.

How we scope

Inventory every embedded Power BI report, its data sources, refresh behavior and the customer tenants that see it.
Decide between Superset guest tokens with row-level security and Metabase embedding options, based on your plan and sign-in needs.
Agree the written scope, deliverables and timeline before work starts, with the tenant isolation test cases named explicitly.

How we build

Deploy Superset with PostgreSQL or MySQL as the metadata database, plus the caching and worker components that alerts and thumbnails need.
Build the host application's server-side guest token flow, using a service account and row-level security rules per tenant.
Configure authentication through OAuth, LDAP or Flask AppBuilder role mapping, and test that tenant data cannot cross boundaries.

How we hand over

Deliver architecture diagrams, runbooks for token issuance, secret rotation and upgrades, and the tenant isolation test results.
Document the security controls and evidence your team can give to auditors, noting that independent auditors issue any attestation.
Run knowledge transfer sessions with your engineers so they can operate the embedded stack without DeployOpen on call.

How we support

Support upgrades with a database backup, a staging test and a review of breaking changes in the release notes before each move.
Offer ongoing support, upgrades and continuous security testing of the embedded surfaces as a retainer after handover.
Ask any provider for written confirmation of the current release, license terms and embedding features for your chosen plan before you commit.