Which embedding model fits a customer-facing product with Superset and Metabase
For a product that puts dashboards in front of external customers and must isolate tenants, the choice depends on tenant count, identity model and whether Metabase branding and SSO are requirements. Apache Superset is Apache-2.0 licensed with no paid edition, and its Embedded SDK uses guest tokens with row level security to scope what each viewer sees. Metabase's SSO, row and column permissions, multi-tenant data segregation and embedding without Metabase branding sit in its paid Pro and Enterprise plans, although guest embeds are available on the open-source edition. Answer these three questions first, because they decide which costs and controls you actually pay for.
Cost follows tenant count and identity model. Superset has no license fee, so its spend is infrastructure and staff: the metadata database, caching, Celery workers and the engineering time to build and maintain the guest token flow. Metabase's pricing page lists Pro at $575 per month, or $517.50 per month billed yearly, with 10 users included and $12 per additional user per month. Enterprise is priced by quote starting at $20,000 per year. Because Metabase prices by user, ask the vendor exactly how embedded end customers are counted before modeling cost. If your customers sign in through your own identity provider, check Metabase's JWT, OIDC and SAML options against Pro or Enterprise, and check Superset's OAuth2 and AUTH_ROLES_MAPPING setup against your provider.
Before committing, run a proof of concept with at least two tenants that hold different data, and confirm that guest token scoping and row level security keep each tenant's rows separate in both tools. Confirm the current embedding setup in the Superset documentation, since SDK details change between releases. Confirm which Metabase release line you will run: Metabase 64 is an LTS release with end of life on December 1, 2027, and Metabase 65 was released on October 12, 2026. Finally, plan for recurring upgrade work in either choice. Superset requires a metadata database backup and staging tests before each upgrade, and Metabase runs application database migrations automatically, so both need an owner.
Embedding capabilities, licensing and plan requirements side by side
This table sets Apache Superset against Metabase on the capabilities that decide a customer-facing embed: license, token embedding, tenant isolation, sign-in, branding, and the services each platform needs in production. Read the Metabase cells for the plan that unlocks each control, and the Superset cells for what to confirm in current documentation. The main takeaway is that Metabase gates several embedding controls behind paid plans, while Superset's cost sits mainly in the services and checks you run yourself.
| Capability | Apache Superset | Metabase |
|---|---|---|
| License and paid edition | Apache-2.0 with no paid edition. Features are not tiered by license. | AGPL open source edition plus paid Pro and Enterprise plans under the Metabase Commercial License. |
| Guest or token embedding | Embedded SDK with guest tokens. Confirm the current token lifetime and signing options in the Superset docs. | Guest embeds are listed for the open source edition. Confirm which embed types each plan includes before you commit. |
| Row-level and tenant isolation | Row level security is available for embedded dashboards. Confirm how tenant filters are set per guest token in your release. | Row and column level permissions, and multi-tenant data segregation, require Pro or Enterprise. |
| SSO for embedded users | OAuth2 providers, LDAP and AUTH_ROLES_MAPPING are documented. Confirm how embedded viewers authenticate. | SSO requires Pro or Enterprise. Open Source and Starter support Google sign-in and LDAP only. |
| Branding of embedded content | Confirm theming and removal of product branding in the Superset embedding docs. No fact is supplied here. | Embedding without Metabase branding is a Pro or Enterprise feature. |
| Metadata database | PostgreSQL 10 to 17 or MySQL 5.7 and 8.x. SQLite and the Compose PostgreSQL container are not recommended for production. | Embedded H2 by default. PostgreSQL is recommended for production, and MySQL 8.4.0 or MariaDB 10.6.0 and later are supported. |
| Workers and caching | Caching layer and Celery worker and beat processes are needed for alerts, async queries and thumbnails. | No worker requirement appears in the supplied facts. Confirm the processes needed for embedded dashboards. |
| Production upgrades | Back up the metadata database, run superset db upgrade and superset init, test in staging and check UPDATING.md. | Migrations run automatically. Back up first, reduce clusters to one node for major upgrades, and check LTS support windows. |
Factors that change the embedding decision in practice
Embedding costs and risks follow from a few questions: how many tenants you serve, whether end users need their own identity, whether branding must go, how fast your user count grows, and who runs the supporting services. Each card below turns one of these into a check you can run against your own product and your own budget before committing to either platform.
Tenant count and data partitioning
Decide first whether each customer gets its own database schema, its own database, or shared tables filtered by a tenant key. With Superset, the tenant boundary is usually enforced through row level security rules and guest token claims that you generate in your own application. With Metabase, multi-tenant data segregation is listed among the paid Pro and Enterprise features. Ask each vendor to show how a query from tenant A is blocked from tenant B's rows, and test that with real credentials before you design around it.
Shared guest identity or individual users
A shared guest identity means your application signs each embed request on behalf of the customer, which suits external viewers who never log in to the BI tool. Individual identity means each end user maps to a BI user with groups and permissions, which needs SSO or user provisioning. Superset supports guest tokens for the first pattern. Metabase guest embeds cover the first pattern on the open-source edition, while JWT, OIDC or SAML sign-in for the second requires Pro or Enterprise. Confirm which pattern your product needs before comparing prices.
Removing Metabase branding
If your customers should not see the Metabase name or logo inside your product, embedding without Metabase branding is a paid Pro or Enterprise feature on Metabase's published pricing page. Superset's Apache-2.0 license places no branding restriction on embedding, but you still need to review the Apache License 2.0 terms and any trademark guidance from the Apache Software Foundation with your legal team. Put branding requirements in writing early, because they can settle the plan decision on their own.
User growth against per-user pricing
Metabase's Starter and Pro plans include a set number of users, then charge per additional user. Model your expected viewer count across the next two or three years, not only today's, and compare the monthly and yearly figures on the pricing page. Superset has no paid edition, so its cost moves with infrastructure and staff time rather than seat count. Ask Metabase whether embedded viewers count toward plan users, because that answer can change the result by a large margin.
Metadata database and Celery operations
Superset runs on a metadata database, which the documentation says should be PostgreSQL or MySQL in production, and most installations add Redis and Celery workers for alerts, reports, async queries and thumbnails. That is a recurring operating cost in engineer time: backups, upgrades, monitoring and sizing. Metabase is lighter on services, but its application database also needs production planning, since the embedded H2 default is for demos. Ask who on your team will own these services after go-live, and price that ownership honestly against a subscription.
Upgrade and version support windows
Both platforms change between releases, and your embedded product inherits every change. Superset's upgrade guide asks you to back up the metadata database, run database upgrades, test in staging and read UPDATING.md for breaking changes. Metabase documents automatic application database migrations and a version support policy that differs for LTS and non-LTS releases. Map each platform's release cadence to your own change control window, and ask the vendor which versions will receive fixes during your planned support period.
How multi-tenant data isolation works in each tool
In Superset, isolation for an embedded viewer comes from two controls you configure together: the guest token that the Embedded SDK uses to identify the viewer and the dashboard they may open, and row level security rules that filter query results for that viewer. The tenant boundary therefore depends on what your application puts into the token and on the RLS clauses attached to each dataset. Confirm in the Superset embedding documentation exactly which token fields are accepted and how RLS applies to guest sessions, because the mapping from token claim to data filter is written and reviewed by your team. Superset has no paid edition, so these controls are available without a license tier change.
Metabase covers the same ground with row and column level permissions and multi-tenant data segregation, both listed on its pricing page as Pro or Enterprise features. Open Source and Starter do not include them, so a multi-tenant design on Metabase starts with a plan decision before any configuration work. Guest embeds on the open-source edition remain available for simpler cases, but you should verify which restrictions apply to guest sessions in your version. The Metabase embedding introduction is the natural starting point, and you should ask Metabase how its group permissions, sandboxing and segregation combine for your tenancy model.
Neither tool is safer by default. Isolation depends on your schema, on whether tenants share tables distinguished by a tenant column or sit in separate schemas or databases, and on the claims your application signs. Build a test with at least two synthetic tenants holding distinct rows, include edge cases such as null tenant identifiers and users who belong to more than one tenant, then open each embedded view as each tenant. Check the SQL editor, exports and cached results too, since a filter that holds on the dashboard can still leak through another path. Repeat the test after every upgrade, because Metabase runs application database migrations automatically and Superset upgrades also change behavior between versions.
What each embedding path costs to license
Apache Superset is released under the Apache License 2.0 and the project has no paid edition, so the license line on this path is zero. The embedded SDK, guest tokens and row level security are part of the open-source project rather than a plan you upgrade to. What you pay for is the infrastructure and the people who run it: the metadata database, the caching layer and any Celery worker and beat processes, plus the engineering time to upgrade and support the platform.
- No license tier to buy: Superset itself carries no per-user or per-dashboard fee, so cost scales with infrastructure and operations.
- Recurring infrastructure: Compute, storage, backups and the metadata database run every month whether or not the dashboards are used.
- Staffing for upgrades: Each upgrade involves backing up the metadata database, running database upgrades and testing in staging, which takes ongoing engineering time.
- Support is self-sourced: Without a paid edition, support comes from your own team or from a services partner you engage under a separate written scope.
Confirm with your own engineers which components your embedding design needs, since the caching and worker services add to the operating footprint.
The Metabase Open Source edition is free to license under the AGPL, and it includes guest embeds. Guest embeds let you show dashboards inside another application without asking viewers to sign in to Metabase. The restrictions that matter for a customer-facing product sit on other plans: SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are not included in Open Source. Metabase's pricing page also lists embedding without Metabase branding as a paid feature, so branding removal is not free.
- Free license: The Open Source edition carries no license fee under the AGPL.
- Guest embeds included: Signed guest embeds are available without a paid plan.
- Paid features excluded: Row and column level permissions and multi-tenant data segregation require Pro or Enterprise.
- Branding is a paid feature: Embedding without Metabase branding is listed on the pricing page as Pro or Enterprise only.
Ask Metabase to confirm in writing which embedding options your use case needs on the free edition, because the pricing page is the reference for what each plan includes.
Metabase publishes prices for Starter and Pro on its pricing page. Starter costs $100 per month or $90 per month billed yearly and includes the first 5 users. Pro costs $575 per month or $517.50 per month billed yearly and includes the first 10 users. Additional users cost $6 per month on Starter and $12 per month on Pro. Starter does not include SSO, row and column level permissions or multi-tenant data segregation, so a multi-tenant embedded product usually needs Pro.
- Starter price: $100 per month, or $90 per month billed yearly, with 5 users included and $6 per month for each additional user.
- Pro price: $575 per month, or $517.50 per month billed yearly, with 10 users included.
- Pro per-user add-on: Each user beyond the first 10 adds $12 per month on Pro.
- Features that force Pro: SSO, row and column level permissions, multi-tenant data segregation and advanced group sync require Pro or Enterprise.
Illustrative example: a Pro subscription with 14 named users would add four users at $12 per month each, on top of the base price. Confirm whether your embedded viewers count as named users under the current pricing terms before you calculate the total.
Metabase Enterprise is priced by quote, and the pricing page states that it starts at $20,000 per year. The Enterprise plan adds to the Pro feature set and is the option for organizations that need the broader contract, support and governance terms that come with a quote. The published starting figure is a floor for planning, not the final number, because the quote depends on the scope, user count and deployment terms agreed with Metabase.
- Starting figure: The pricing page states a starting price of $20,000 per year for Enterprise.
- Quote-based pricing: The final amount depends on scope and terms, so it cannot be read from the page.
- Recurring annual cost: The subscription recurs each year, while the setup work on your side is a separate one-time effort.
- Scope of the quote: Ask Metabase what user volume, support level and deployment model the quote covers, and whether embedded viewers are included.
Before signing, ask for the quote in writing and confirm the renewal terms, the price change conditions and the support window for the version you deploy.
Neither the Superset figure of zero nor the Metabase plan prices include the infrastructure and staffing that run the platform. Those costs sit with your organization whichever path you choose, and they are often larger than the license line for a customer-facing product. They include hosting for the application, the metadata database and any caching or worker services, backups, monitoring, upgrades and security reviews, and the people who do that work.
- Hosting: Compute, storage and network costs for the application and its database recur monthly in your cloud or data center.
- Database operations: Backups, restores and upgrades of the metadata database take planned engineering time.
- Upgrade effort: Metabase runs database migrations automatically, and Superset requires manual database upgrade steps, so each path has its own recurring effort.
- Engineering and support: Internal staff or a services partner work under a separate written scope.
Ask any vendor or services partner for a quote that separates license, hosting, implementation and ongoing support, so you can compare the two paths on the same basis.
How to test tenant isolation and embedding before you commit
This sequence lets you check, in your own environment, whether each tool keeps one customer's data away from another and whether the plan you would buy covers the SSO, branding and operations your product needs. It ends with a documented go or no-go record for each platform.
Define two or more test tenants
Your product or security lead creates at least two synthetic tenants with distinct datasets, distinct user groups and a few rows that must never be visible across the boundary. Use fake data only. Record which tenant key (for example, an account ID or organization claim) separates them. The step is done when a written tenant matrix lists each tenant, its users, its tables and the expected visible rows per user. This matrix becomes the pass criteria for every later step.
Build an embedded dashboard in each tool
Your platform engineers build the same dashboard in Superset and in Metabase, backed by the same test tables. For Superset, configure the Embedded SDK and issue guest tokens from your backend. For Metabase, configure guest embedding on the open-source edition and, separately, the SSO-based or full-app embedding you would need to evaluate on a paid plan. Confirm the embedded page loads inside a test host application. The step closes when each dashboard renders for each test tenant from your own application, not only from the admin console.
Verify row-level filters block cross-tenant reads
A tester logs in or requests tokens as tenant A and then attempts to reach tenant B's rows through the dashboard, filter parameters, SQL Lab or the Metabase question editor, where those are exposed. Confirm the filter is enforced by the tool, not only by the front end: check whether the guest token or JWT claim scopes the query, and whether row-level security rules apply to every dataset the dashboard touches. Also test tampered or missing claims. The step is done when no test query returns another tenant's rows and each failed attempt is logged. Ask each vendor to confirm how their filtering behaves for datasets reached through custom SQL.
Check SSO and branding against the plan you would buy
Your identity and procurement leads list the sign-in and branding features the product needs, such as SSO, group mapping, provisioning and removal of vendor branding. Map each item to the plan that includes it using the current published tables for Metabase and the Superset documentation for its authentication options. Confirm with the vendor in writing which edition or plan includes each feature. The step produces a feature-to-plan matrix. Treat any gap as a cost input for the quote, not as an assumption that a feature is included.
Load test the metadata database and workers
Your platform team runs a controlled load against a staging deployment that mirrors production topology, including the metadata database, cache, and Celery worker and beat processes if Superset uses them for async queries, alerts or thumbnails. Measure dashboard response time per tenant, database connection use, queue depth and worker restarts at several concurrency levels. These are things to measure, not benchmarks, so the results apply only to your data volumes and hardware. The step is done when you have a sizing note showing where each component reaches its limit and which service needs monitoring.
Review the upgrade path for both tools
Your operations lead follows each vendor's upgrade documentation in a staging copy of the deployment. For Superset, back up the metadata database, run the documented database upgrade and init commands, and check the upgrade notes for breaking changes between your current and target versions. For Metabase, back up the application database, check the migration constraints in the upgrade guide, and confirm that a single-node reduction is possible during a major upgrade. If you start on the H2 default, test the documented load-from-h2 step with the same version that last wrote the file. The step closes when you have a dated runbook and a rollback plan for each tool.
Record the go or no-go decision
Your CISO or product owner reviews the tenant matrix, filter test results, feature-to-plan matrix, sizing note and upgrade runbook side by side. Ask each vendor or implementation partner for a written quote that matches the scope tested, including the plan, user counts and any support you expect. The step is complete when a single decision record states which tool passed, which requirements were not met and what must be confirmed before production use.
What running either tool in production asks of your team
Running Superset in production means operating more than one web process. The application needs a metadata database, and the Superset architecture documentation says SQLite, the default in Quickstart and PyPI installs, is not recommended for production, with PostgreSQL and MySQL the tested options. Your team should also decide whether to run the optional caching layer and Celery worker and beat processes. Async queries, alerts and reports, and dashboard thumbnails depend on them, and most installations use Redis and Celery. For a customer-facing embed, confirm with your own load tests whether those features are part of the product, because they add services to monitor and size. Also confirm the deployment method. The Superset 6.1.0 documentation describes the official Helm chart for Kubernetes, but the current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator, so check the Superset Kubernetes installation guide against the version you plan to ship.
Superset upgrades follow a fixed sequence. Back up the metadata database, run superset db upgrade and superset init, and test the new version in staging first. Read UPDATING.md for breaking changes between versions before you schedule the change. Because the embed depends on guest tokens and row level security settings, add a check for embedded dashboards and tenant filters to the staging test. Metabase is a different operational pattern. It runs application database migrations automatically at startup, so the backup of the application database is the main safeguard. The Metabase upgrade docs recommend reducing a cluster to a single node for major upgrades because of a migration lock, and they recommend upgrading release by release from versions older than 40. Plan a maintenance window for that step.
Metabase's embedded H2 application database is for demos. The Metabase documentation recommends PostgreSQL for production, and MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4 are also supported. If an existing install still runs on H2, the documented load-from-h2 command moves it, but it must run with the same Metabase version that last updated the H2 file, so verify that version before you start. On support windows, Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027, and LTS versions receive support for 14 months, while non-LTS versions usually end support after 2 months. Ask your vendor or check the Metabase version support page for the current schedule before committing an embedded product to a release line. Whichever tool you choose, the cost of operations is mainly your team's time for upgrades, staging tests and on-call coverage for the extra services.
Questions buyers ask before hiring outside help
Is embedding Apache Superset free to license?
Yes, the Superset software itself carries no license fee because Apache Superset is released under the Apache License 2.0 and the project has no paid edition. You still pay for the infrastructure that runs it, including the metadata database, the caching layer and any Celery worker and beat processes that your embedded use depends on. Your internal engineering time and any outside implementation work are separate costs that come from the written scope, not from the license. Ask any vendor, including Preset, to confirm in writing which components they charge for and which they do not.
What does Metabase embedding cost at my user count?
The answer depends on which features your embedding needs, because the Metabase pricing page places SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing only in the Pro and Enterprise plans. Its Open Source plan is free, while 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. Additional users cost $6 per month on Starter and $12 per month on Pro. Enterprise is priced by quote starting at $20,000 per year. Confirm current figures on the pricing page and ask how embedded viewers are counted before you model cost.
How long does a proof of concept take?
No duration is supplied for this comparison, so treat any timeline you hear as something to verify against a written scope. The length of a proof of concept is driven by how many data sources you connect, whether tenant isolation must be proven with real customer data patterns, which identity provider you must integrate, and how many embedded views you need to demonstrate. Ask the vendor or partner to name the tenant model they will test, the sign-in path, the environment they will use and the exact acceptance checks before agreeing to a timeline.
What does the work need from our internal team?
Expect to supply people who own identity, the database access model and the application that hosts the embedded dashboards. On the Superset side, your team needs to operate the metadata database, plan the upgrade path using the upgrade guidance (back up the metadata database, run the database upgrade and initialization commands, test in staging and check UPDATING.md), and own the secret key handling. On the Metabase side, your team needs to run the application database, which the documentation recommends placing on PostgreSQL for production, and plan upgrades. Name a product owner for tenant rules and a platform owner for the running service before work starts.
Can our team build and run the embedding without outside help?
Often yes, if your engineers already run web services, understand OAuth2 or SAML flows and have a clear plan for tenant isolation. The hard parts are rarely the chart configuration. They are the sign-in path, the row-level rules that keep one customer from seeing another's data, the upgrade discipline and the monitoring of background services. Score your team against those four areas. If two or more are thin, a fixed-scope engagement that covers design, build, handover and documentation may cost less than learning under production pressure.
What does a fixed-scope engagement typically cover?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For an embedding project, a written scope usually names the platform to be deployed, the data sources, the tenant isolation design, the sign-in integration, the embedded views, the hardening steps, the backup and upgrade procedure, the documentation and the handover. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own infrastructure, but it does not issue audit reports or certifications. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so ask for a quote tied to that written scope.
How do we check that tenant data stays isolated?
Start by writing down the isolation model you need: which tenant sees which rows, whether tenants share one database or use separate ones, and how embedded tokens carry tenant identity. Superset uses guest tokens with row-level security for embedded dashboards, and Metabase uses row and column level permissions that sit in its paid plans. Test both with accounts from different tenants, including attempts to reach another tenant's filters through the URL or the API. Ask any vendor or partner to show the test results, and confirm the controls with your own security team rather than relying on a demo.
When embedding should decide the choice between Superset and Metabase
Choose Apache Superset when licensing cost must stay at zero and your team can run the services around it. Superset is Apache-2.0 licensed and has no paid edition, so the recurring cost is the infrastructure and engineering time you spend operating it. Plan for a metadata database, which the project tests with PostgreSQL and MySQL and does not recommend running on the SQLite default for production. Caching and Celery workers are optional for basic dashboards, but if your embedded product also needs alerts, reports or async queries, budget for Redis and workers as well. Upgrades require a metadata database backup, superset db upgrade and superset init, and a staging test against UPDATING.md. If your team cannot staff that work, the zero license line will not hold.
Choose Metabase when customer-facing embedding must look like part of your product, SSO is required, and permissions must be handled without custom code. Removing Metabase branding, SSO and full-app embedding sit in the Pro and Enterprise plans, as do row and column level permissions and multi-tenant data segregation. Published Pro pricing is $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 how embedded end users are counted, because that count will drive the bill more than the list price. Review the Metabase embedding documentation and move the application database from the embedded H2 default to PostgreSQL before production.
Settle the decision with a tenant isolation test before you sign anything. For Superset, confirm that your guest token and row level security rules return only one customer's rows when a second tenant's token is used, and check the Embedded SDK behavior in the release you plan to run. For Metabase, test the same boundary on a Pro trial, since multi-tenant segregation is a paid control. Then compare the two costs on the same basis: Superset's staff hours, hosting and upgrade work against Metabase's plan, user count and Enterprise quote if SSO and branding force that tier. The sibling pricing comparison walks through that arithmetic, and the BI comparison covers the wider tradeoffs.
How DeployOpen helps you evaluate and implement embedded BI
DeployOpen approaches Apache Superset vs Metabase embedding as a written scope first, then a build in your own infrastructure, with the tenant isolation and licensing questions settled before any code is written. Work is fixed-scope, so the evaluation, implementation and handover deliverables are agreed in writing before work starts.
How we scope
- Confirm which embedded views, user roles and customer tenants the product must serve.
- Map each required feature to a Superset or Metabase capability, and flag which Metabase features need Pro or Enterprise.
- Record the written scope, deliverables and timeline with you before any build work starts.
How we build
- Deploy the chosen platform and its metadata database in your cloud account, data center or air-gapped network.
- Configure guest tokens or signed embedding, row level security and tenant filters, then test isolation between customer accounts.
- Integrate identity providers and group mappings, and run security testing against the embedded dashboards and their APIs.
How we hand over
- Document the architecture, configuration keys, tenant isolation tests and the licensing position for each platform.
- Provide upgrade and backup runbooks, including metadata database backups and staging-first upgrade steps.
- Walk your platform, security and product teams through operation, so they can run the embedded BI stack without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover version upgrades, re-running isolation tests and reviewing changes to licensing or features.
- Ask any provider, including us, to confirm current plan features and included users in writing before you commit.
