Open-source alternative to QuickSight embedded analytics

Open-source alternative to QuickSight embedded analytics: the short answer

If your product team pays session capacity for anonymous or embedded readers and wants that cost to follow your own infrastructure instead, the two main self-hosted options are Apache Superset, using its embedded SDK and guest tokens, and Metabase, using its embedding features. Both run in your environment, so you pay for compute, storage, and the people who operate them rather than for each reader session. Tenant isolation, however, is not something either product grants on its own. It is the host application's job: your server must decide which customer a viewer belongs to and request a scoped token for that customer only. For Superset, the host app's server requests guest tokens from /api/v1/security/guest_token/ using a service account, and that request can carry row-level security rules that restrict what the embedded viewer sees. The feature flag EMBEDDED_SUPERSET must be set to True before the embedded SDK and guest token endpoint work. Confirm that your application never passes a client-chosen filter into the token request, and test that one tenant's token cannot read another tenant's rows.

For Metabase, embedding capabilities and identity features depend on the plan. Single sign-on through JWT, OIDC, or SAML, and row and column level permissions, are documented for the Pro and Enterprise plans rather than the free Open Source edition, so read the current Metabase pricing page before you choose a design. Ask Metabase which embedding options are included at each tier, and confirm them against your own tenant model. Whichever tool you choose, plan the isolation tests, the service account credentials, and the upgrade path as part of the initial scope, because those are the controls auditors and your customers will ask about first.

Which QuickSight embedded capabilities map to which open-source options

This table maps the embedded analytics capabilities a QuickSight host application usually relies on to the Apache Superset and Metabase mechanisms that provide them. Read each row as a question to answer in your own environment, and treat the coverage notes as the points to confirm before committing to a plan. The main takeaway is that Superset's guest tokens and Metabase's plan tiers put tenant isolation and SSO costs in different places.

Capability	Apache Superset	Metabase	Coverage note
Embedded dashboard display	Embedded SDK (@superset-ui/embedded-sdk) with the EMBEDDED_SUPERSET feature flag set to True	Signed embedding of dashboards and questions from the host application	Confirm the embedding mode and iframe or SDK options in each vendor's embedding documentation before building
Anonymous or reader access	Host server requests a guest token from /api/v1/security/guest_token/ using a service account	Signed embedding with the host issuing the token, so viewers need no Metabase account	Confirm whether each option allows fully public access without any host session, and how token lifetimes are set
Per-viewer row restrictions	Row-level security rules included in the guest token request	Row and column level permissions, available only on Pro or Enterprise plans	Metabase row-level permissions require Pro or Enterprise; Open Source and Starter do not include them
Branding and theming	Dashboard and theme configuration in Superset, with embedding limited to what the SDK exposes	Appearance settings and embedding parameters set by the host	Confirm which elements can be hidden or restyled in the host page, since this varies by version
SSO into the host app	Host authenticates users; guest tokens avoid Superset logins, while OAuth2 and LDAP cover internal authors	Host-side signed embedding avoids Metabase logins; JWT, SAML and OIDC for internal users need Pro or Enterprise	Confirm which SSO protocols your internal authors need and which plan includes them
Admin and author work	Authors and admins use the Superset UI with roles mapped through AUTH_ROLES_MAPPING	Authors and admins use Metabase with groups and permissions managed in the application	Plan who builds dashboards and who operates the application database, the metadata store on each side
Tenant isolation responsibility	Host app must set RLS rules correctly on every token request, since Superset enforces only what the token states	Host app must sign the correct parameters per tenant, and multi-tenant data segregation is a Pro or Enterprise feature	Test isolation with two tenant accounts and confirm the signing and token logic in your own code review
Upgrade and operation	Upgrades follow the Superset upgrade documentation, with metadata backups and staging tests	Upgrades run application database migrations automatically, with a backup and a single node for major upgrades	Assign who tests each release, since embedding behavior can change between versions

Apache Superset or Metabase for embedded reads: when each fits

Both tools can serve dashboards inside another application, but they differ in how the embed is authenticated, which features sit behind paid tiers, and how often the platform must be upgraded. The cards below set out what to check for each before choosing one for embedded readers.

Superset embedded SDK and guest tokens

Superset embeds dashboards through the @superset-ui/embedded-sdk package, and the EMBEDDED_SUPERSET feature flag must be set to True before the SDK and guest token endpoint work. Your host application's server, acting through a service account, requests a guest token from /api/v1/security/guest_token/, and that token can carry row-level security rules for each viewer. Confirm that your backend builds those rules from the authenticated user's tenant, never from browser input.

Superset operating components

Superset runs a Flask and React application, a metadata database, and optional caching and Celery worker processes. The architecture documentation says alerts, async queries and dashboard thumbnails need the caching layer and workers, and most installations use Redis and Celery for them. Metadata belongs on PostgreSQL or MySQL in production, so budget for backups, upgrades with superset db upgrade and staging tests on every release.

Superset Kubernetes deployment path

The 6.1.0 documentation describes Kubernetes installs with the official Helm chart, but the current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. Teams standardizing now should plan on the Operator and confirm its maturity, supported features and upgrade path against their own cluster. Existing Helm-based installs need a dated plan for moving over.

Metabase embedding and paid tiers

Metabase's free Open Source edition allows unlimited users and dashboards on your own servers, which suits internal reads. SSO and row and column level permissions, the controls most embedded tenant models need, sit in the Pro and Enterprise plans, and multi-tenant data segregation does too. Before choosing Metabase for customer-facing reads, confirm which embedding and permission features your target plan includes with Metabase directly.

Metabase LTS and non-LTS cadence

Metabase LTS versions receive support for 14 months, while non-LTS versions usually reach end of life after 2 months. Choosing a non-LTS release means upgrading roughly every two months to stay supported, which is a standing operations commitment. Metabase 64 is an LTS release with end of life on 1 December 2027, so an LTS line is the lower-effort default for embedded reads that must stay stable.

Metabase application database and upgrades

Metabase ships with an embedded H2 database meant for demos, so production needs PostgreSQL or MySQL 8.4.0 or MariaDB 10.6.0 or later with utf8mb4. Upgrades run database migrations automatically, and the docs advise backing up the application database, reducing a cluster to one node for major upgrades, and stepping through each release from versions older than 40. Ask your team who owns these steps and how a failed migration is restored.

How the host app enforces tenant isolation with guest tokens

The host application, not the browser, decides which tenant a viewer belongs to. In a Superset embedding, the host server calls the /api/v1/security/guest_token/ endpoint using a service account and asks for a guest token that names the dashboard and attaches row-level security rules. Those rules are what restrict the rows each embedded viewer can see. The browser receives only the resulting token and passes it to the embedded SDK. The tenant identifier used to build the RLS clause must come from the host's own authenticated server-side session, such as a verified user record or a claim the server has validated, and never from a query parameter, a request body or a value the front end sends. If the host reads the tenant from the client, any user can change it and read another customer's rows. A misconfigured token or RLS rule fails silently, which is why it needs deliberate testing. A rule that is too broad, a clause that is not scoped to the tenant column, a token issued with a shared or reused service account identity, or a dashboard that exposes a dataset without the rule attached can all return data across tenants without any error. Before launch, the team should confirm the exact token payload fields and RLS rule format against the current embedding documentation for the Superset version in use, since the shape of the request is version-specific. Then test with at least two synthetic tenants: request tokens for each, confirm each returns only its own rows on every chart and in exported data, and try to alter the tenant value in the browser, the token and the URL to see whether anything changes. Plan the controls around the token as well as the query. Set short token lifetimes, keep the service account's permissions to the minimum needed to request guest tokens, log every token request with the tenant and dashboard it was issued for, and make sure the Superset metadata database and the warehouse role used by Superset cannot bypass the rules. Ask your Superset implementation partner to document these decisions in the same scope as the embedding work, because the auditor-facing evidence for tenant separation is the test record and the configuration, not the design intent.

Moving embedded dashboards from QuickSight to self-hosted Superset

This sequence moves embedded dashboards off session-based QuickSight billing and onto a self-hosted Superset stack in which the host application decides who sees which rows.

Inventory embedded dashboards and reader populations
The product owner and the host application team list every embedded dashboard, the tenants or customer groups that view it, the number of readers per tenant, and the datasets each dashboard reads. Record which readers are anonymous, which are authenticated through the host app, and how often sessions occur, because that pattern drives the cost comparison later. The step is done when every embedded view maps to a dataset, a tenant rule and an owner, and the list is signed off by both teams.
Export asset bundles as a reference only
An engineer runs QuickSight asset bundle export jobs for the embedded analyses, dashboards and datasets and stores the JSON or CloudFormation definitions in version control. These files serve as a rebuild specification, not as an import path, because Superset does not load QuickSight definitions. Confirm with the QuickSight export documentation which data sources the bundle omits, and export those definitions separately. The step is complete when each embedded dashboard has a stored definition and a list of gaps is documented.
Reconnect datasets directly to the warehouse
A data engineer creates Superset database connections to the same warehouse or SQL sources the QuickSight datasets read, using a Python DB-API driver and SQLAlchemy dialect for each source. Each dataset is defined as SQL or a physical table with the columns the charts need, and the connection credentials are kept in the Superset configuration or a secrets store, not in dashboard code. The step is done when each dataset returns the same row counts and key totals as its QuickSight counterpart for a sample period agreed with the business owner.
Choose a replacement for SPICE
SPICE is QuickSight's in-memory store, so the team decides how each embedded dataset will be served once it is no longer cached there. Options include querying the warehouse directly, using Superset's caching layer for repeated queries, or placing a query engine such as ClickHouse or Trino in front of large fact tables. Ask the warehouse owner what query load and concurrency the source can sustain. The step closes with a documented choice per dataset and a caching or query engine sized against the tested concurrency.
Rebuild charts and row-level rules
Analysts recreate each embedded chart and dashboard in Superset, then define row-level security rules that match the tenant boundaries the host app enforces. Superset guest tokens can carry row-level rules, so the tenant filter should be expressed once in the token request and tested on every dataset. Each rebuilt dashboard is compared against its QuickSight original by the business owner. The step is complete when each dashboard matches the approved specification and every tenant rule has a test case.
Build the host token service
The host application team builds a server-side token service that holds a Superset service account, authenticates the end user in the host app, and requests a guest token from the guest token endpoint with the tenant and row-level rules for that user. The Superset instance must have the EMBEDDED_SUPERSET feature flag set to True, and the browser loads the dashboard through the embedded SDK using the returned token. The service never exposes the service account to the browser. The step is done when a token issued for one tenant cannot be used to load another tenant's dashboard in a manual test.
Run staging tests for cross-tenant leakage
Before any production traffic moves, the security and QA teams run a staging test plan that requests tokens for pairs of tenants, attempts to read rows and filters belonging to the other tenant, and checks dashboard exports, caching behavior and the metadata database for unintended exposure. Staging runs on a Superset metadata database of PostgreSQL or MySQL with a tested backup and restore, and the team follows the upgrade documentation before any version change. The step closes with a written test report and sign-off from the security owner.
Cut over and retire session-based billing
The team switches the host application to Superset embedding in stages, keeping QuickSight available for rollback until the new path has run cleanly for an agreed period. After cutover, the team removes embedded reader sessions from QuickSight, cancels or reduces session packs and deletes SPICE datasets once backups of the definitions are stored. Confirm with the QuickSight account owner which subscriptions and capacity items must be cancelled to stop recurring charges. The step is complete when no embedded traffic reaches QuickSight and the cancellation is confirmed in writing.

Running self-hosted embedded BI next to AWS and the rest of the stack

Most teams do not switch every QuickSight user on the same day. Embedded readers, internal authors and the warehouse behind them can move at different speeds, and each boundary creates a risk to plan for. The cards below cover the coexistence decisions that matter most before an embedded reader is moved to Superset or Metabase.

Splitting internal authors from embedded readers

Internal authors often need QuickSight's authoring tools for longer than the embedded audience does, so the two groups can be moved on separate schedules. The risk is that a dashboard is edited in one tool while a copy lives in the other, and the versions drift apart. Decide which tool is the system of record for each dashboard before the first embedded reader is cut over, and confirm that per-session billing for embedded readers stops only after the new embed path is verified.

Keeping Athena and warehouse sources in place

Superset and Metabase both connect to SQL sources through standard drivers, so the existing Athena, Redshift or other warehouse connections can usually stay where they are. The risk is that a dashboard depends on a QuickSight SPICE copy, which does not exist in the new tool and must be replaced by live queries, caching or a query engine. List every dataset that uses SPICE, confirm query cost and latency against the source, and confirm the IAM role or database user the new tool will use has read access only.

Coexisting identity through the host app

For embedded readers, the host application already authenticates users, so the BI tool should not become a second login system for them. Superset issues guest tokens from the host server using a service account, which means the host decides who receives a token and which rows it may see. The risk is that a token request is built from client-supplied values, so confirm that the host server derives tenant and role claims from its own session before calling the token endpoint.

Placing the BI tier near the warehouse

Superset and Metabase send queries to the warehouse, so network placement determines latency, egress and which private endpoints must be reachable. Running the BI tier in the same VPC or region as the data source usually keeps query traffic private, while the embedded host application reaches it through an internal route. The risk is an embedded page that works in testing but times out in production because the BI tier sits behind a different network boundary. Confirm routing, DNS and security group rules from the host application to the BI tier and from the BI tier to each data source.

Running two metadata and worker stacks

A self-hosted Superset runs a metadata database, an optional caching layer and optional Celery workers, and these become the operational footprint that replaces QuickSight's managed service. During coexistence, both stacks must be patched and monitored at once. The risk is that the team treats the new stack as a pilot and leaves its backups and secret rotation undefined. Assign an owner for the metadata database backups and for the SECRET_KEY before the first embedded user is moved.

Reconciling row-level rules across two tools

Row-level rules in QuickSight and the rules passed in a Superset guest token can drift apart during migration. A reader may see different rows in the old and new dashboards, which is a data exposure risk if the new rule is looser. Write each rule once in the host application, test it with a set of sample tenants in staging, and compare row counts between the two tools for the same identity before the cutover.

What do teams ask before replacing QuickSight embedding?

What does replacing QuickSight embedding cost, and which components drive it?

The cost splits into one-time work and recurring operations. One-time work covers migrating datasets, rebuilding dashboards, building the host application's token flow and testing. Recurring cost covers the metadata database, hosting for the web application, and, if you enable alerts, async queries or thumbnails, a cache and Celery workers. Superset is Apache-2.0 with no paid edition, so software licensing is not the line item. Ask any quote to separate infrastructure, upgrade labor, support and migration effort, and to state which of those recur each year.

How long does an embedded migration take?

Duration depends mostly on how many embedded dashboards you have, how many data sources they query, and how much row-level logic must be rebuilt. A small set of dashboards on one warehouse is a different project from dozens of dashboards across several sources with per-customer rules. No duration figure applies to every estate. Ask for a schedule tied to written deliverables, and confirm whether the quote includes staging tests of the guest token flow before any customer-facing cutover.

What must our team run after the migration?

Your team owns the stack after go-live. In practice that means the Superset web application, the metadata database (PostgreSQL 10 to 17 or MySQL 5.7 and 8.x are the supported versions), the host application's server that requests guest tokens with a service account, and the SECRET_KEY that must be set before Superset starts. If you use alerts or reports, you also run the caching layer and Celery workers. Upgrades follow the documented sequence: back up the metadata database, run superset db upgrade and superset init, test in staging, and read UPDATING.md.

Can we test tenant isolation in-house before go-live?

Yes, and you should. Guest tokens can carry row-level security rules that restrict which rows an embedded viewer sees, so the rules themselves sit in your host application's token request. Test them with accounts from each tenant, including attempts to request another tenant's rules, and record the results. Have a second engineer review how the host server builds those rules. An external security test can add an independent view, and DeployOpen's application security testing is one option, scoped in writing before work starts.

Does Metabase's free edition cover embedded row-level needs?

Usually not on its own. Metabase's free Open Source edition is self-hosted with unlimited users and dashboards, but the pricing page places row and column level permissions, SSO, multi-tenant data segregation and usage auditing in the Pro and Enterprise plans. If your embedding depends on per-tenant row restrictions, budget for Pro or ask the vendor to confirm current inclusions. Also confirm which Metabase version you will run, since Metabase 64 is an LTS release supported through 1 December 2027.

When should we bring in a consultant instead of doing it ourselves?

Consider outside help when the embedded product is customer-facing, the tenant rules are complex, or your team has not run a Python web application with a database and workers in production. A consultant is also useful when you need a written plan with deliverables before committing budget. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing first. Ask for a quote built from your dashboard inventory and data sources.

What should a quote for this migration include?

Ask for a line-item quote that separates these parts:

Inventory of embedded dashboards, datasets and data sources
Superset installation with metadata database, cache and workers as needed
Host application changes for guest token requests and row-level rules
Tenant isolation test plan and results
Staging rehearsal, cutover and rollback steps
Upgrade, backup and support terms after go-live

For each line, confirm whether it is one-time or recurring, and ask what would change the price, such as a larger dashboard count or extra data sources.

What to confirm with your team and vendors before choosing

Start by confirming, for the exact Superset or Metabase version you plan to run, that the embedding features you need are available and enabled. For Superset, verify that the EMBEDDED_SUPERSET feature flag can be set to True in your build, that your host application can call the /api/v1/security/guest_token/ endpoint from its server with a service account, and that row-level security rules can be attached to guest tokens as your tenant model requires. Check the embedding documentation for the version you select, because embedding details can change between releases. For Metabase, confirm with Metabase whether your embedding model is covered by the free Open Source edition or requires a paid plan, and read the current embedding introduction before you design around it. Do not assume a feature listed for one plan or version applies to another.

Next, confirm the Metabase plan requirements that affect the embedded context. The pricing page places SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing in the Pro and Enterprise plans, and the people and groups documentation places JWT, OIDC and SAML setups in the same tiers. Ask Metabase in writing which plan covers the exact isolation mechanism your host application will use, and whether the price is per user or per plan at your expected seat count. Also confirm with your team whether the embedded viewers are anonymous, authenticated through your identity provider, or both, since that choice drives which controls you need. Data residency is the other check: confirm where the application database, cache and worker processes must run, whether any vendor service or license check sends data outside your environment, and whether your auditors need that answer documented.

Finally, get an expected session volume from the product owner and the finance team before you size anything. Session volume, peak concurrency and the number of distinct tenants determine the number of web and worker processes, the database capacity and whether a caching layer is needed for dashboard performance. Ask your team to name the owner for upgrades, backups of the metadata database and security patches, and to confirm that the staging environment can test tenant isolation before each release. Ask DeployOpen and your other vendors for a written scope that lists the environments, the tenant isolation tests and the handover documents, so the quote reflects your actual volume rather than an estimate.

How to test tenant isolation before go-live

This sequence checks, with evidence, that a Superset guest token and its row-level rules keep each tenant's dashboards and data out of reach of every other tenant before embedded analytics reaches customers. It produces a dated test record that your security and compliance team can hand to auditors.

Define tenant boundaries and test accounts
Your application team and security lead agree which tenant identifiers, datasets, dashboards and row-level filter values belong to each test tenant, then create two test tenants in a non-production Superset and host app. Record the identifiers in a test plan that names the owner of each tenant. The step is complete when the plan lists every dataset and dashboard that each tenant should see and every one it must not see.
Issue guest tokens with differing row-level rules
Your host application server requests a guest token from the guest token endpoint for each test tenant, using the service account, with row-level security rules that match that tenant's identifier. Keep the request and response logs for each token. The step is complete when you hold two tokens with distinct rules and can show which rule each token carries.
Attempt cross-tenant reads in the browser
A tester loads the embedded dashboard with the tenant A token, then tries to reach tenant B content by changing filters, URL parameters, chart drill-downs, and cached or saved views, and records what each attempt returns. Repeat the checks with the tenant B token. The step is complete when every attempt is logged with a screenshot or export and each shows only the rows the token permits.
Attempt cross-tenant reads through the API
A tester or a script calls the chart and dashboard data endpoints directly with the tenant A token, using identifiers that belong to tenant B, and also replays requests with altered or missing guest tokens. The expected result is an authorization error or an empty result, never another tenant's rows. The step is complete when each request and response is saved and any leakage is raised as a defect.
Verify the service account has least privilege
Your identity administrator reviews the role and permissions granted to the service account that requests guest tokens, confirming it can request embedded tokens and nothing more, such as editing datasets or reading the metadata database. The reviewer also confirms that embedded readers hold only the embedded role. The step is complete when the role export and the review notes are stored with the test record.
Check logging and alerting for access events
Your operations team confirms that authentication, guest token issuance and failed data requests are written to logs that leave the Superset host and are retained under your own policy. A tester then triggers a denied request and checks that it appears in the central log with the token context needed to trace it. The step is complete when a sample event from each category can be found in the log store.
Document results as evidence for auditors
The project owner compiles the test plan, token and request records, screenshots, role export, log samples and a signed list of defects with their resolution, then retests any fix. Your compliance lead maps the evidence to the control objectives your auditor will assess. DeployOpen can prepare the controls and the evidence package, but independent auditors and certification bodies issue any audit report or attestation, so confirm with your auditor which evidence format they expect before go-live.

How DeployOpen scopes and delivers an embedded BI replacement

DeployOpen starts from the written scope of your embedded analytics: which dashboards reach external readers, which data sources they query, and how your host application issues access. We then plan, implement, test and document a self-hosted Apache Superset or Metabase deployment inside your own infrastructure, with a handover your team can run.

How we scope

Inventory the dashboards, datasets and reader groups that your host application embeds today.
Map each external reader to the tenant, row-level rule or guest token claims your app must send.
Agree in writing which embedding pattern, metadata database and authentication model are in scope.

How we build

Deploy Superset or Metabase with PostgreSQL metadata storage and the caching and worker components your alerts and async queries need.
Configure the embedded SDK or signed embedding, service account credentials and row-level rules for each tenant.
Test tenant isolation with negative cases so one customer's guest token cannot read another customer's rows.

How we hand over

Deliver architecture, configuration and tenant-isolation test records as documentation your team keeps.
Walk your operators through backups of the metadata database, secret key handling and staged upgrade steps.
Provide runbooks for issuing guest tokens, rotating keys and reviewing which embedded dashboards are live.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, version upgrades and continuous security testing are available as a retainer.
Ask for the support boundary, response expectations and upgrade responsibilities in the written quote.