Why embedded analytics for SaaS products is a tenant isolation and licensing decision first
When customers ask for dashboards inside your product, the decision that matters most is not which charts look best. It is how each tenant is kept to its own rows and what the license allows you to do with the software you distribute. The two main self-hosted candidates are Apache Superset, licensed under Apache-2.0 with no paid edition, and Metabase, which is licensed under the AGPL outside its enterprise directory and gates SSO and row-level permissions behind its paid Pro and Enterprise plans. Choosing between them means settling tenant isolation and distribution terms before you compare visualization features.
Tenant isolation in an embedded setting is enforced by the embedding layer and the data layer together. A signed embed or guest token has to carry the tenant identity, and row-level security has to filter every query against that identity so a customer can never see another customer's rows, even through an edited request. Confirm with the vendor how each candidate maps your tenant claim to a filter, whether the filter applies to cached results and exports, and which of those controls sit in the free edition. Your security team should test this with two tenants holding overlapping identifiers before any customer sees a dashboard.
Licensing shapes the rest of the plan. The AGPL requires you to offer source code to users who interact with a modified version over a network, so the question of whether your changes to Metabase count as modifications, and whether your product is a combined work, needs written legal advice before you ship. Superset's Apache-2.0 terms carry fewer distribution obligations, but you still need to review the notices and any third-party components in your stack. Put these questions to your counsel and your implementation partner first, because they determine whether you can modify the product, which features you must pay for, and how a commercial plan changes your obligations.
Which requirements a SaaS embedded analytics build must meet
This table maps each requirement that a SaaS embedded analytics build faces to the source that creates it, what it means for the build and the evidence to keep. Read it as a checklist for the architecture and the contract: several rows depend on which Metabase plan or Superset configuration you choose, so confirm those early.
| Requirement | What it means for the build | Evidence to keep or ask for |
|---|---|---|
| AGPL obligations if Metabase is modified | Distributing a modified Metabase under the AGPL can require releasing your corresponding source. Unmodified use inside your product still needs a license review against how you ship and host it. | Written license analysis from counsel, a record of any Metabase source changes and your distribution model |
| Apache-2.0 terms for Superset | Superset is Apache-2.0 with no paid edition, so the license imposes attribution and notice duties rather than source disclosure. Keep the NOTICE file and dependency license inventory with each release. | Dependency and license inventory per release, attribution notices in the product |
| Metabase plan gating for SSO and tenant controls | SSO, row and column level permissions, multi-tenant data segregation and usage auditing are included only in Pro and Enterprise. Open Source and Starter cannot meet these requirements, so budget the plan choice into the design. | Current Metabase pricing page reviewed at contract time, plan named in the scope |
| Metabase embedding identity options | JWT, OIDC and SAML setups need Pro or Enterprise. Guest embedding and tenant-scoped filters must be designed so a customer can never reach another tenant's rows. | Test results showing cross-tenant access is blocked, configuration exported and reviewed |
| Superset SECRET_KEY and key rotation | Superset will not start without a user-specified SECRET_KEY, and PREVIOUS_SECRET_KEY supports rotation. Store the key in a secrets manager and plan rotation windows with the upgrade process. | Key storage record, rotation runbook, change tickets for each rotation |
| Superset metadata database and caching layer | Use PostgreSQL or MySQL for production, not SQLite or the Compose PostgreSQL container. Alerts, reports, async queries and thumbnails need the caching layer and Celery workers. | Supported version matrix (PostgreSQL 10 to 17, MySQL 5.7 and 8.x), architecture diagram |
| Data Act switching rights | Data processing service providers must let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. Exporting dashboards, roles and metadata in open formats supports this. | Documented export procedure, contract clause on exit and data return |
| GDPR Article 28(3) processor terms | Where you process customer personal data through the dashboard stack, the contract must bind you to process only on documented instructions and to apply Article 32 security measures. Tenant data flows must match what the contract describes. | Data processing agreement, processing register entries, sub-processor list |
| SOC 2 Trust Services Criteria if customers ask for a report | Security common criteria CC1 to CC9 apply to every SOC 2 examination. A Type 1 report covers design as of a date, a Type 2 report adds operating effectiveness over a period, and SOC 2 reports are generally restricted to specific users. DeployOpen prepares controls and evidence; an independent CPA firm issues the report. | Control matrix mapped to CC1 to CC9, access review records, change and logging evidence for the review period |
Which open-source BI platforms fit SaaS embedding and why
Two platforms dominate open-source embedded analytics for SaaS products, and they differ mainly in license posture and in which features sit behind a paid plan. The cards below cover each platform, the upstream data preparation layer and the decision factors that should drive the choice between them.
Apache Superset as the Apache-2.0 option
Superset is licensed under Apache-2.0 and has no paid edition, so the licensing review is simpler than with AGPL software. It is built on Flask-AppBuilder and supports OAuth2 providers and LDAP, with AUTH_ROLES_MAPPING translating identity groups into Superset roles. Check that your team can operate the metadata database, the caching layer and the Celery workers that alerts and async queries depend on.
Metabase open source and its AGPL terms
The open source edition of Metabase is licensed under the AGPL, and its enterprise directory uses a separate commercial license. If you modify Metabase and make it available to users over a network, the AGPL obligations apply to that modified code, so take legal advice before changing the source. Confirm with counsel how the AGPL applies to your product architecture.
Paid plan gates for SSO and row-level permissions
SSO, row and column level permissions and multi-tenant data segregation are included only in Metabase Pro and Enterprise, not in Open Source or Starter. Open source and Starter support Google sign-in and LDAP, while JWT, OIDC and SAML require Pro or Enterprise. Ask any vendor or partner to show these features working in a tenant-isolation test before you commit to a plan.
Metabase JAR backend and operations
The Metabase backend is written in Clojure and Java and runs as a JAR, which simplifies deployment on virtual machines or containers. It uses an embedded H2 database for demos, so production needs PostgreSQL or MySQL as the application database, with a documented one-time migration path. Plan backups before every upgrade, since migrations run automatically and clusters may need reduction to a single node for major upgrades.
Metabase LTS support window
Metabase 64 is an LTS release published on 16 September 2026, supported until 1 December 2027. LTS versions receive support for 14 months, while non-LTS releases usually reach end of life after about two months. Choose the LTS line for a customer-facing product and confirm your upgrade cadence against the end-of-life dates before committing to a version.
Upstream data preparation with Dagster or Airflow
Dashboards are only as reliable as the tables behind them, and Dagster (Apache-2.0) or Apache Airflow (Apache-2.0) can build and schedule the tenant-scoped reporting tables that the BI layer reads. Keeping heavy transformations upstream protects production databases from ad hoc dashboard queries. Treat these orchestrators as data preparation only, not as the BI platform itself.
Choosing on license posture and team skills
Choose Superset if Apache-2.0 terms and no paid edition matter most, and Metabase if its interface and paid support suit your buyers and you accept the AGPL review. Your team's skills decide the operating cost: Superset needs strong Python and Flask operations, while Metabase needs Clojure-aware troubleshooting and a paid plan for multi-tenant security. Confirm both against a written scope before selecting.
How a SaaS team rolls out embedded dashboards in phases
The sequence moves from tenant and license decisions through isolation testing, staged release and a repeatable upgrade routine, so each phase produces evidence that the next one depends on. Each phase closes with a named artifact that the product, security and legal owners can review.
Decide tenant model and license position
Product, security and legal leads agree how tenants map to workspaces, groups and data sources, and which distribution model applies. For Metabase, confirm early whether the team needs the AGPL source obligations to apply to its product, and whether row-level and column-level permissions, SSO and multi-tenant segregation require the Pro or Enterprise plan according to the current pricing page. For Superset, which is Apache-2.0 with no paid edition, record the license review and any notice requirements for the product. The phase closes with a signed tenant model document and a written license decision that legal has reviewed.
Design the analytics replica and warehouse
Engineering decides where dashboards query: a read replica, a separate analytics database or a warehouse fed by a pipeline, so that customer-facing queries never run against the transactional production database. The team sizes the metadata database (PostgreSQL or MySQL, not the SQLite default), sets query timeouts and caching, and defines which tables carry the tenant key. The phase closes with an architecture diagram and a load test report showing dashboard query behavior against the replica under expected concurrency.
Build identity and guest token integration
The team connects the product's login to the embedding layer so that each viewer receives only their tenant's scope. For Superset this means OAuth2 or a custom OAuth2 server with group-to-role mapping through AUTH_ROLES_MAPPING. For Metabase embedding, the team implements signed embedding or SSO through the paid tiers the pricing page lists. Secrets such as SECRET_KEY are generated and stored in the organization's secret manager. The phase closes with a working integration in development and a list of every identity claim that drives row-level filters.
Build the tenant isolation test suite
QA and security engineers write automated tests that log in as users from at least two tenants and attempt to reach each other's dashboards, cards, saved questions, filters, exports, alerts and API endpoints, including direct URL access and changed filter parameters. The suite runs on every build and on every upgrade. The phase closes with a passing test run in continuous integration and a signed tenant isolation test report that names the tested paths, the test accounts and the known gaps.
Run a cross-tenant leak test in staging
A staging environment mirrors production configuration, including the replica, caching layer, workers for alerts and reports, and the identity provider. An independent tester attempts cross-tenant access with realistic but synthetic data, and the team reviews the access logs to confirm that denied requests are recorded. Findings are fixed and retested. The phase closes with a leak test report, a list of resolved findings and a sign-off from the security owner before any customer sees the feature.
Pilot with a small set of customers
The team enables embedded dashboards for a limited group of customers agreed in advance, monitors query load on the replica, reviews tenant access logs and collects feedback on filters, theming and performance. Support staff use a runbook for common issues such as missing filters or slow queries. The phase closes with a pilot review that records incidents, query performance observations and the changes made before general release, agreed by product and security leads.
Release generally and document the upgrade routine
After the pilot review, the team opens the feature to all eligible customers and writes an upgrade runbook for the platform. The runbook covers backing up the metadata or application database, running the vendor's upgrade steps, checking the release notes for breaking changes, and rerunning the isolation test suite in staging before production. For Metabase, the runbook also covers the application database migration lock and the LTS support window. The phase closes with a published runbook, a rerun isolation test report for each upgrade and a named owner for the platform.
What the AGPL means if Metabase is modified and embedded
The AGPL obligations can attach when a modified version of Metabase is offered to users over a network, even if you never distribute copies of the software. That network clause is the point most SaaS teams miss. Embedding an unmodified open source edition in your product is a different question from shipping changes to Metabase's code, and your legal team should treat those two cases separately from the start. Metabase publishes its open source edition under the AGPL (LICENSE-AGPL.txt) and its commercial editions under the Metabase Commercial Software License (LICENSE-MCL.txt), as described in the Metabase GitHub repository. Confirm which license file covers each component you run, including any enterprise directory code.
The Metabase Commercial Software License governs the commercial editions, not the AGPL portion of the codebase. If you buy a paid plan, read the commercial terms for what they permit and restrict, and do not assume a paid subscription changes how the AGPL applies to the open source code you modify. Your decisions here are concrete: whether you will patch the application or only configure it, whether custom code lives inside Metabase or in your own application that calls its embedding features, and whether you need to show or offer source to users of the modified service. Write down each modification you make and the reason for it, so the record exists when counsel asks.
This page does not give a legal conclusion on any of these questions. Obtain your own legal opinion from counsel who knows open source licensing and your distribution model, and ask them to review the exact license text in the version you deploy. Pair that review with an engineering inventory of changes to the Metabase image, JAR or configuration. Engineering can confirm what was modified, and counsel can decide what it means.
How query load stays off production databases
A read replica is a copy of the production database that streams changes from the primary and serves read queries. It is the shortest path to isolating dashboard reads from write traffic, because the BI tool connects to the replica using the same schema the application uses. The trade-off is freshness and fit. Replica lag is usually small, but it grows under heavy write load, and the replica still carries the production schema, so dashboard queries that scan large tables can compete with other reads on the same instance. Row-level security must be enforced on the replica the same way it is on the primary, and the replica needs its own capacity planning.
- Freshness: Customers see data as of the replica's lag, so confirm the acceptable lag with product owners before launch.
- Load isolation: Long analytical scans still consume CPU, memory and I/O on the replica, which limits the benefit for wide queries.
- Schema coupling: Dashboards depend on production table structures, so application migrations can break saved charts.
- Cost: The replica is an always-on instance that is paid for each month, and it grows with the primary.
- Failover: Confirm how the replica is promoted and how Superset's metadata and cache connections behave during failover.
Ask the database team to show replica lag under a realistic write burst before accepting this option.
An analytics warehouse is a separate database built for scans and aggregations, loaded from production by a pipeline. Tools such as Apache Airflow or Dagster schedule and monitor the loads, and Airbyte or a custom job can move changes from source systems. Dashboards then query a model designed for reporting, which removes analytical load from the transactional system entirely. The cost is engineering work: the pipeline, its tests, data quality checks, and tenant-aware models must all be built and operated. Freshness depends on the schedule, so near-real-time dashboards need streaming or micro-batch designs that add further complexity.
- Freshness: Data is as current as the last successful load, so publish the refresh interval on each dashboard.
- Isolation: Tenant keys should be carried into every reporting table so row-level security applies to the warehouse itself.
- Operations: Failed loads, schema drift and backfills need alerting and a runbook.
- Cost: Build effort and the warehouse infrastructure are paid up front and then recur through hosting and maintenance.
- Scale: Columnar engines such as ClickHouse suit high-volume tenant data, but the choice should follow measured query patterns.
Ask for the refresh schedule, the failure alerting design and a test of tenant filters on the reporting tables.
Cached extracts run a query once on a schedule or on demand and store the result, so dashboards read the stored result rather than the source. This keeps production load predictable and limits it to the refresh job. It works well for dashboards where customers look at the same totals repeatedly. The main risks are staleness, cache key design and data leakage: a shared cache entry must never be returned to a tenant who should not see it. Cache keys must include the tenant and the effective row-level filter, and the cache must be cleared when permissions change.
- Freshness: Results are only as current as the last refresh, which often suits daily or hourly reporting.
- Tenant keys: Include tenant identity and filter values in every cache key to prevent cross-tenant reuse.
- Invalidation: Define what clears the cache when source data or user entitlements change.
- Cost: Cache storage and refresh compute recur, while design and testing are largely one-time.
- Visibility: Cached values can be stale without the viewer noticing, so display the last refresh time.
Ask how cache keys are constructed and whether a test proves that one tenant cannot read another tenant's cached result.
Apache Superset separates its application from the components that handle heavier background work. Per the Superset architecture documentation, the platform has four components: the Flask and React application, a metadata database, an optional caching layer, and optional Celery worker and beat processes. Alerts and reports, async queries and dashboard thumbnails require the caching layer and worker components, and most installations use Redis and Celery for them. Superset is tested with PostgreSQL and MySQL as the metadata database, and the SQLite default is not recommended for production. Superset 6.1.0 was published on May 13, 2026, and the official Helm chart is marked deprecated in current development documentation in favor of the Apache Superset Kubernetes Operator.
- Async queries: Long queries run in workers so web requests return without holding a connection open.
- Thumbnails: Dashboard previews are generated by workers, which should be sized separately from interactive capacity.
- Alerts and reports: Scheduled deliveries run in workers and should be kept off the request path.
- Metadata database: Use PostgreSQL or MySQL in production, within the supported versions in the configuration documentation.
- Operations: Back up the metadata database and follow the upgrade steps in the documentation, including checking UPDATING.md.
Confirm that the worker pool has its own resource limits so background jobs cannot starve interactive customer queries.
Load testing shows whether the chosen design holds when many tenants open dashboards at the same time. The test should use representative tenant data volumes, realistic filter combinations and a mix of interactive views, exports and scheduled jobs. It should measure query latency on the production database and on the replica or warehouse, lag or refresh time, cache hit behavior, worker queue depth and error rates. Tests should run against a staging copy that matches production sizing, and results should be compared to the agreed service targets. Security testing should run alongside load testing, because heavy traffic can expose cache or filter defects that normal use does not.
- Peak scenario: Simulate the busiest reporting window your customers use, such as month-end.
- Isolation check: Confirm that the production database sees no dashboard queries once the design is in place.
- Queue behavior: Measure how long workers take to clear alert and thumbnail backlogs under load.
- Tenant leakage: Verify row-level filters and cache keys under concurrent sessions for different tenants.
- Repeatability: Keep scripts and datasets so the test can rerun after each Superset or Metabase upgrade.
Ask for the load test plan, the pass criteria and the results before production launch.
How much does it cost and how long does it take to embed self-hosted dashboards?
What drives the cost of embedding dashboards in a SaaS product?
The cost depends mostly on the tenant model, the number of data sources, how identity is connected and how much pipeline work is needed before data is ready to chart. A single shared database with a tenant column and row-level security is less work than one database per customer. Each additional source system adds modeling, credentials, refresh logic and testing. Theming and custom embedding inside your frontend add design and integration effort. Ask any partner to split the quote into these components so you can see which ones your product actually needs.
What do Metabase paid plans cost for embedded analytics?
According to the Metabase pricing page, the Open Source plan is free, Starter is $100 per month or $90 per month billed yearly with the first 5 users included, and Pro is $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. SSO, row and column level permissions and multi-tenant data segregation are included only in Pro and Enterprise, so tenant isolation features usually drive the plan choice. Confirm current prices with Metabase before budgeting, since list prices can change.
Does Apache Superset have a licensing cost?
Apache Superset is released under the Apache License 2.0 and the project has no paid edition, so there is no license fee to pay. Your costs are the infrastructure to run it, including the metadata database, and the caching and worker components that alerts, reports and async queries need. Most installations use Redis and Celery for those components. The licensing cost is zero, but build, hosting, upgrade and security work still apply, and they are the larger share of the total for most teams.
What recurs after the dashboards go live?
Recurring work includes hosting and the analytics database, backups of the metadata database, security patching, version upgrades and regression testing of embedded views after each release. Superset upgrades require a metadata database backup, running superset db upgrade and superset init, testing in staging and checking UPDATING.md for breaking changes. Metabase upgrades run application database migrations automatically, so backups and staged testing matter just as much. Budget for these as an ongoing operating cost, not a one-time project cost, and ask whether a retainer covers them.
What does the reader need to provide before an engagement starts?
A partner will need the list of data sources and their owners, the tenant model and how tenant identifiers are stored, the identity provider used by your product, and the target hosting environment and its network rules. You should also provide the dashboards and metrics customers need, the expected number of tenants and concurrent users, and your release process for the SaaS product. Without these inputs, a fixed-scope quote cannot be written reliably. Agree on who signs off on security decisions, such as row-level security tests, before work starts.
Can an internal team build this alone?
An internal team with strong data engineering, frontend and security skills can build it, particularly for a small number of tenants and one data source. The work becomes harder when row-level security must be enforced and tested for every tenant, when identity mapping must follow your product's roles, and when query load must be kept off production databases. Consider whether your team has capacity for ongoing upgrades and testing, not only the first release. Many organizations split the work: internal staff own the data model and product integration while a partner handles hardening, documentation and handover.
How long does an embedded analytics rollout take?
Duration depends on the number of data sources, the complexity of tenant isolation and how much of the pipeline has to be built before dashboards can be shown. A single-source pilot with one embedding pattern is much shorter than a multi-source rollout with SSO, theming and performance testing. Ask for a timeline that lists the discovery, build, security testing and handover phases separately, and confirm which phases depend on your team's availability. DeployOpen does not publish fixed durations; timelines are agreed in writing in each scope.
What should a quote for embedded analytics include?
A useful quote lists the deliverables, the tenant isolation approach and how it will be tested, the identity integration, the data sources in scope, the embedding method, hardening and backup setup, documentation and handover, and what is excluded. It should also state who pays for infrastructure and licenses, and what the recurring support or upgrade retainer covers. Ask whether the price includes row-level security testing against multiple test tenants. Fixed-scope quotes make it easier to compare options, so request the same scope from each vendor.
Build, partner or commercial BI embedding: which path fits
Building on Apache Superset means your own engineers own the application, the embedding layer and the tenant model. Superset is released under the Apache License 2.0 and the project has no paid edition, so the software itself carries no license fee. The cost moves to people and infrastructure: engineers who build the embedding flow, implement row-level security and guest token handling, run the metadata database and optional caching and worker components, and perform upgrades by backing up the metadata database, running superset db upgrade and superset init, testing in staging and reading UPDATING.md for breaking changes.
- One-time work: embedding integration, tenant model design, theming, security review and the first production rollout.
- Recurring work: upgrades, patching, on-call for alerts, reports and async queries, and secret rotation with PREVIOUS_SECRET_KEY.
- Control: you decide where tenant isolation is enforced, which data stays in-region and how the audit trail is kept.
- Switching: because the code and data sit in your infrastructure, moving to another platform later is mostly a rebuild of the presentation layer, not a data export negotiation.
- Who pays: your payroll or your implementation partner's fixed-scope fee, plus cloud or data center costs.
Before committing, ask an implementation partner to estimate the in-house skills required and confirm the Superset version you will standardize on.
Self-hosting Metabase is a middle path. The open source edition is licensed under the AGPL, but the features that matter for customer-facing dashboards sit in paid plans. According to Metabase's pricing page, SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included only in Pro and Enterprise, so an open source deployment is not enough for tenant-separated embedding. Enterprise is priced by quote starting at $20,000 per year, and Pro is listed at $575 per month or $517.50 per month billed yearly with the first 10 users included. The Pro price and user terms should be checked on the pricing page at the time of purchase.
- Recurring license cost: subscription fees for the plan and any additional users, which scale with the number of people who log in.
- Partner work: deployment, PostgreSQL application database, identity integration, embedding setup and upgrade runbooks.
- Upgrade discipline: the Metabase upgrade docs recommend backing up the application database and reducing a cluster to a single node for major upgrades because of a migration lock.
- Control: you still host the platform, so residency and tenant isolation remain in your hands, but the vendor sets feature boundaries.
- Switching: the application database and dashboard definitions can be exported, but confirm the export format and the rework needed on the new platform.
Ask a partner to show the exact feature list required by your identity and embedding model, and to quote the plan tier that covers it.
Commercial embedded BI moves most platform work to a vendor. You pay a subscription, usually priced by user, capacity or embedded session, and the vendor operates the application. The trade-off is that tenant data, query logs and some metadata may be processed in the vendor's environment, which matters for data residency and for any customer contract that limits where data is processed. Because the platform is proprietary, the switching path depends on the vendor's export tools and on the terms your customers accept. DeployOpen does not sell or resell commercial BI, so any vendor pricing must come from that vendor's quote.
- Recurring fees: subscription or usage charges that grow with customers, users or embedded sessions.
- Vendor work: hosting, upgrades, base security controls and feature roadmap, documented in the vendor's contract and security pack.
- Your work: integration, data model, tenant mapping and review of the vendor's subprocessors and data processing terms.
- Residency: check where the vendor processes data and whether you can keep the query layer in your own region.
- Switching: under the EU Data Act, data processing providers must let customers switch providers, with a maximum two-month notice period and a 30-day transitional period, and switching charges end on 12 January 2027. Confirm these terms in the contract.
Ask the vendor for its exit plan, export formats and data processing agreement before signing.
What evidence customers and auditors ask for from embedded analytics
This table maps the evidence customers and auditors ask for to the component that produces it, from access logs to upgrade records and SOC 2 control descriptions. Use it to decide which artifacts your team must generate and retain before a customer security review or audit. DeployOpen prepares this evidence, but independent auditors issue any report.
| Evidence | Where it comes from | What to confirm before you rely on it |
|---|---|---|
| Access logs and usage analytics (who viewed which dashboard) | Metabase usage analytics and auditing, which the pricing page lists only in Pro and Enterprise plans | Confirm your plan includes this feature, and confirm where logs are stored and how long they are retained |
| Tenant isolation test results | Test scripts run against row-level security and guest token scopes in a staging environment, with saved outputs per release | Confirm each test uses two tenants with real data sets and that failures are recorded, not overwritten |
| Change records for upgrades | Upgrade tickets that follow the Superset upgrade steps (database backup, db upgrade, init, staging test, UPDATING.md review) or the Metabase upgrade docs | Confirm each change record names the source and target versions and the staging test result |
| Backup records for the application database | Backup job logs and restore test results for the Superset metadata database or the Metabase application database | Confirm restores have been tested, not only backups scheduled, and that backups are encrypted and stored separately |
| Secret and configuration management | Records showing SECRET_KEY rotation with PREVIOUS_SECRET_KEY and the handling of embedding signing keys | Confirm who holds the keys, where they are stored and when they were last rotated |
| SOC 2 control descriptions | Written descriptions of how security common criteria CC1 to CC9 apply to the embedded analytics system and its hosting | Confirm the system boundary includes the BI tier, the metadata database and the embedding layer, and that a licensed CPA firm issues any report |
| Data processing and subprocessor records | Processor contract terms and records of the instructions given to the analytics platform for processing customer data | Confirm the contract reflects documented processing instructions and the list of hosting locations |
Questions to ask an embedded analytics implementation partner
Start with how row-level security is enforced for each tenant, because this is where embedded dashboards most often leak data. Ask the partner which layer applies the tenant filter: the Metabase or Superset data model, the signed embedding parameters, or the database itself through per-tenant roles or views. Ask how the filter is tested. A credible answer names a test suite that logs in as users from two or more tenants, requests every embedded dashboard and chart, and checks that no rows from another tenant come back, including through drill-through, CSV export, saved questions and cached query results. Ask for those test cases in the written scope and whether they run again after each upgrade.
Next, ask how guest tokens or SSO embedding will be implemented in your product, and who owns the signing key. For Metabase, ask which embedding method is planned and confirm that JWT or SAML-based identity features are on the plan the partner recommends, since the Metabase pricing page places SSO and row and column permissions in the Pro and Enterprise plans. For Superset, ask how guest tokens are issued, how their lifetime is set, and how the secret key is rotated (using the PREVIOUS_SECRET_KEY mechanism described in the configuration documentation). Ask who signs tokens and whether your backend, not the browser, creates them.
Ask the partner to name the exact Metabase features your design depends on and the plan each requires, and to put that list in the scope. Ask how query load is kept off production databases: a read replica or analytics copy, query timeouts, caching, and a separate application database for Metabase or Superset metadata. Ask how the AGPL obligations apply to your product. Under the AGPL, modifications to Metabase that users interact with over a network can trigger source disclosure, so ask whether any code changes are planned, how they will be isolated, and who will review the licensing position before release. Ask for that position in writing, and check it with your own counsel. For the final two points, ask for a fixed deliverable list covering the tenant test suite, the embedding configuration, the upgrade runbook and the data export at exit, including how the partner will return dashboard definitions, users and permissions in a documented format and remove tenant data from the embedded platform.
Deployment patterns for embedded analytics in a SaaS platform
An embedded analytics deployment is more than a dashboard tool. It is a set of connected components: a metadata database for the BI platform, an analytics store that keeps queries off production, a caching and worker layer for scheduled and asynchronous work, an identity integration that carries tenant context, and a cluster deployment that can be upgraded safely. Each choice affects tenant isolation, query load and how much operational work your team takes on.
Application database for BI metadata
The BI platform stores dashboards, questions, users, permissions and connection settings in its own application database, separate from your product data. For Metabase, the docs recommend PostgreSQL for production and the embedded H2 database is meant for demos. Superset is tested with PostgreSQL and MySQL, and its SQLite default is not recommended for production. Confirm the exact version range you will run, back up this database before every upgrade, and plan for a one-time migration if a pilot started on H2.
Analytics store or read replica
Customer-facing dashboards should not run heavy aggregations against the transactional database that serves your product. Decide whether dashboards query a read replica, a separate analytical store or a pre-aggregated reporting schema. Each option changes data freshness, cost and the work needed to keep tenant columns correct. Ask your team to measure the slowest expected dashboard against the replica before launch, and to set query timeouts so one tenant cannot starve others.
Caching and worker layer
Superset's alerts and reports, async queries and dashboard thumbnails need a caching layer and Celery worker and beat processes, and most installations use Redis and Celery for them. Metabase needs its own capacity planning for scheduled subscriptions and caching. Decide who operates the queue, how failed jobs are retried and how cached results are scoped so one tenant's cached data is never served to another. Treat this layer as part of the customer-facing service, not an internal extra.
Identity and tenant context
Tenant isolation depends on how the product tells the BI platform who is asking. Options include SSO through OIDC, SAML or OAuth2, group or attribute mapping into roles, and signed guest or JWT tokens issued by your backend for an embedded session. Superset maps LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING. In Metabase, JWT, OIDC and SAML sit on Pro or Enterprise plans, so confirm the plan before design. Test that a token for one tenant cannot be altered to read another.
Cluster deployment and upgrade path
For Superset, the official Helm chart is marked deprecated in current development documentation, which points new deployments to the Apache Superset Kubernetes Operator. Confirm which path your platform team supports before writing manifests. Upgrades need a metadata database backup, superset db upgrade and superset init, a staging test and a review of UPDATING.md. For Metabase, upgrades run migrations automatically, and major upgrades may require reducing a cluster to a single node. Build a rehearsed upgrade runbook into the rollout.
How DeployOpen scopes and supports embedded analytics for SaaS teams
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For an embedded analytics program, that means the Superset or Metabase deployment, its metadata database, caching layer and workers, and the analytics database it queries all run in infrastructure the SaaS company controls. Most engagements are fixed-scope, so the written statement of work should name each component, the tenant isolation method (guest tokens with row-level security, or SSO-based embedding), the authentication setup, the backup and restore procedure, and the handover documents before any work starts. DeployOpen does not publish a price list; a quote follows from that written scope.
The deliverables that matter most for a multi-tenant product are the ones a security reviewer or customer auditor will ask for. Ask for the tenant isolation test cases and their results, the role and group mapping that feeds row-level filters, the runbook for rotating the Superset SECRET_KEY or Metabase embedding secrets, the upgrade procedure with a staging test step, and the list of licensing decisions made for distribution. Continuous testing and upgrades are offered as retainers rather than one-time work, because a dashboard platform changes with each release and each new tenant. Cross-tenant security testing, where testers try to read another customer's rows through filters, guest tokens or API calls, is a separate scope item that should be agreed and dated in writing. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and the SaaS company should confirm with its own auditor which evidence that auditor will accept.
