Open source embedded analytics: which stack fits a product or portal
A product or portal team that must show per-customer dashboards to external users has a narrower problem than internal business intelligence. Apache Superset (Apache-2.0) and Metabase (AGPL outside its enterprise directory) are the main self-hosted options, and the choice depends on three things: the license terms you can accept for a customer-facing service, the tenancy model that separates one customer's data from another's, and the access model that decides who sees what inside a shared dashboard. Product leads own the user experience and the embedding roadmap, data leads own the semantic layer and the query paths, and security leads own identity, isolation and evidence. At regulated organizations, these three groups need to agree on the stack before a prototype turns into a commitment.
The license question is the first filter and it is easy to underestimate. Superset is distributed under Apache-2.0, which is permissive for hosting and modifying the code. Metabase's core is AGPL, which carries source-availability obligations when you modify and offer the software over a network, and its enterprise directory falls under the Metabase Commercial License, so features such as certain embedding and security controls may depend on which edition and license you use. Have counsel map each feature you need to a license file before design starts, and confirm the current terms in the repository's LICENSE files rather than relying on secondhand summaries. The second filter is the access model. Ask whether each external customer should see the same dashboard filtered by row, a separate workspace per tenant, or a signed embed with a server-issued filter. Then test the answer against the platform: confirm which row-level security, role and embedding mechanisms the chosen release supports, how identity is passed from your portal into the analytics layer, and what audit records are produced. A build-versus-buy decision follows from these answers, so run a short proof of concept with two tenants and a leak test before the scope is written.
What to agree on before choosing an embedded analytics platform
Embedded analytics fails less often on the chart library than on decisions made early about tenants, data access and evidence. The cards below set out the choices a product, security and compliance team must settle together before comparing Apache Superset and Metabase. Each one names the decision and the owner who should make it.
Tenant isolation model
Decide whether each customer gets its own database, its own schema, or shared tables filtered by a tenant key. Shared tables are cheaper to operate but put all isolation on query logic, so one faulty filter can expose another customer's rows. Separate schemas or databases make audits simpler and increase operational work for upgrades and provisioning. The product owner and the CISO should sign this decision together, and the platform team should confirm how each candidate tool stores dashboards and datasets per tenant.
Row-level security rules
Write the rules that decide which rows a viewer sees, and decide where they are enforced. Rules kept only in the BI layer are easy to bypass if someone queries the warehouse directly, so the data team should consider enforcing them in the database or a view layer as well. Test each rule with real end-user identities, including users who belong to several tenants. The data owner approves the rules, and the security engineer confirms the tests.
Identity federation and token exchange
Decide how a customer's login becomes a BI session with the right tenant and role. This covers single sign-on with your identity provider, how group or tenant claims map to dashboard permissions, and whether the product passes a short-lived token or uses a service account with embedded user context. Confirm the lifetime of embedded sessions and how they end when a user is removed. The identity architect owns this decision, with the application team consulted on the embedding flow.
Who authors dashboards
Decide whether dashboards come only from your internal analysts, from customers through a self-service builder, or from a mix in which customers can change filters but not the underlying queries. Customer-authored content raises the risk of unbounded queries, exposed datasets and inconsistent metrics. Set the rules for publishing, review and retirement of content. The product manager and the analytics lead own this decision, and the platform team must know who can create datasets.
Performance targets for external users
Set the number of concurrent external users, the acceptable time for a dashboard to render at peak, and the largest query a customer may trigger. External users behave differently from internal analysts because they arrive in bursts and expect product-level response times. Ask each candidate for benchmark evidence at your expected load and confirm which caching layer and query timeout settings are supported. The platform engineering lead owns the targets, and the product owner signs off on them.
Audit and logging evidence
Define which events must be logged, such as logins, dashboard views, exports, permission changes and failed access attempts, and how long those records are kept. Customers and auditors will ask who saw which tenant's data and when. Confirm that the chosen tool can send logs to your central store with tenant identifiers attached, and that exports are logged as well as views. The compliance lead owns the retention requirement, and the security operations team owns the log pipeline.
Apache Superset, Metabase and other options compared
This table compares Apache Superset and Metabase on license, embedding model, row-level security, SSO, authoring and operating effort, then adds a custom front end option. Read it as a shortlist filter: the license and the embedding model usually decide the choice before features do.
| Criterion | Apache Superset | Metabase | Custom front end on a charting library |
|---|---|---|---|
| License | Apache-2.0. Version 6.1.0 was published May 13, 2026. | AGPL outside the enterprise directory. The enterprise directory uses the Metabase Commercial License. Version v0.64.1 was published October 7, 2026. | Depends on the charting library chosen. Confirm the license of every component you ship to customers. |
| Obligations when embedding | Apache-2.0 places few obligations on how you ship or modify the code. Confirm the terms with your counsel for your product. | AGPL obligations can apply if you modify Metabase and make it available over a network. Enterprise features need a commercial agreement. Confirm which obligations apply to your use. | Your team owns the code, so obligations depend on your own product licensing and third-party library licenses. |
| Embedding model | Embedding of dashboards and charts into external applications. Confirm the current embedding method and supported authentication flow in the release you plan to deploy. | Embedding through signed or interactive modes. Confirm which modes your edition supports and whether they fit your tenancy model. | Full control of the rendered view, navigation and data calls, at the cost of building and maintaining that layer. |
| Row-level security | Available as a built-in feature. Confirm how it maps tenant identifiers from your application to query filters before committing to a design. | Available as a feature, with some controls in the enterprise edition. Confirm the exact scope in your edition. | Enforced by your own API and query layer. Requires explicit tenant scoping in every query path. |
| SSO | Supports common identity protocols through configuration. Confirm the supported protocols and group mapping in the version you deploy. | Supports SSO through its paid enterprise tier. Confirm which protocols are included in your license. | Handled by your application's identity layer, which you already operate or must build. |
| Authoring model | Analysts build charts and dashboards in the web interface, with SQL Lab for ad hoc queries. Suits teams comfortable with SQL. | Business users ask questions through a guided query builder, with SQL available for analysts. Lower barrier for non-technical users. | Developers define each chart and interaction in code. Changes require a release cycle. |
| Operating effort | Depends on the team's skills in database tuning, upgrades and caching. Ask the implementation partner to estimate effort against your staff and environment. | Depends on the team's skills in database connections, upgrades and application hosting. Ask for a scoped estimate tied to your environment. | Highest ongoing effort, since the team maintains the front end, its security and its release cadence. |
| Best fit | Teams with SQL-capable analysts and a need for broad chart types and self-service exploration. | Teams that want guided self-service for business users and a simpler authoring experience. | Products that need a tightly controlled user experience and can staff front end engineering over time. |
What AGPL and the commercial license mean for a shipped product
Metabase is AGPL-licensed outside its enterprise directory, and that choice shapes what you can ship. The AGPL is a copyleft license with a network-use clause, which means that if you modify Metabase and let external users interact with it over a network, the obligation to offer them your corresponding source may apply even when you never distribute copies of the software. Whether your embedding model, such as iframe embedding, a white-labeled portal, a custom plugin or a fork, triggers that obligation is a legal question, not a technical one. Ask counsel to review the exact architecture: which Metabase code you change, whether your own application code is combined with it, and whether customers receive any part of the software. Check the current license text directly in the Metabase LICENSE file before the review, and record the version you intend to deploy.
The enterprise directory is different. It is covered by the Metabase Commercial License, a separate agreement, so any feature you rely on from that directory needs its own written terms and cannot be assumed to share the AGPL position. Confirm with the vendor which capabilities you need for multi-tenant access, SSO or row-level controls, whether they sit in the enterprise directory, and what the commercial license permits for hosted or embedded use, including redistribution and the number of tenants or end users it covers. Price and term questions belong in that vendor conversation, not in this page.
Apache-2.0 for Apache Superset generally carries fewer copyleft constraints than AGPL. Superset is licensed under Apache-2.0, a permissive license whose main obligations are attribution and notice, so many teams find the legal review shorter. That is a general reading, not a conclusion for your product. Counsel should still confirm that your notice, attribution and any changes you publish meet the license terms, and that no bundled dependency adds a different license. Ask your team to produce a software bill of materials for the chosen stack, because the license exposure of an embedded analytics product is the sum of every component, not just the headline platform.
Reference architecture components and how they connect
An embedded analytics deployment is a chain of trust: the host application decides who the user is, a token service turns that identity into a narrowly scoped analytics session, and the analytics platform enforces data access before any query reaches the source. Each component below has a defined job and a defined limit, and the weakest link usually sits where one of those limits is missing.
Host application and token service
The host application authenticates the end user and asks a token service to issue a short-lived, signed embedding token. That token should carry the tenant identifier, the dashboard or resource it may open, and the row-level filter values the user is entitled to. The host and token service must never hand the analytics platform a shared administrator login or a database password. Check token lifetime, signing key rotation and what happens when a customer's account is deprovisioned mid-session.
Analytics platform and metadata database
Apache Superset or Metabase runs as a separate service with its own metadata database that stores dashboards, charts, datasets, users and permission definitions. Keep this database on a private network segment, backed up and encrypted, and reachable only from the platform. Confirm which embedding and row-level security features your chosen version supports and test them in staging, because the exact capability set varies by release and edition. Do not let embedded end users reach the platform's administration interface.
Caching layer
A query cache reduces load on source systems when many tenants open the same dashboards. The risk is cross-tenant leakage: a cached result computed with one user's row-level filter must never be served to another user. Cache keys must include the tenant and the effective security context, and cache time-to-live should be set per dataset sensitivity. Ask the implementation partner to demonstrate that two tenants with identical dashboards receive different cached results.
Semantic and modeled data layer
A governed layer of curated views or a semantic model defines the business meaning of metrics and the joins users may run. Analysts and embedded users query this layer, not raw operational tables. Tenant isolation is easier to prove when each tenant's data is separated by schema, by a tenant column enforced in every view, or by database role, and the choice should be documented before build. Ask who owns metric definitions and how changes are reviewed.
Source databases and warehouse
Analytics reads from operational databases, a replica or a warehouse. The platform's database connection should use a read-only role scoped to the modeled views, with no write, DDL or access to other schemas. Prefer a read replica or warehouse for heavy dashboards so that customer-facing transactions are not slowed by analytical queries. Confirm connection pooling limits per tenant so that one large dashboard cannot exhaust shared capacity.
Logging and monitoring
Log authentication events, token issuance, dashboard views, query text and the tenant and filter values applied, while keeping personal data in logs to the minimum needed. These records let you show who saw what and investigate a suspected cross-tenant exposure. Set retention deliberately, because logs of this kind can contain personal data and are themselves subject to protection duties. Ask the partner how alerts for failed token validation and unusual query volume are routed to your security operations team.
How row-level security and multi-tenant access are enforced
In a shared schema, every tenant's rows live in the same tables, and isolation depends on a filter that is applied to every query. In Apache Superset, row-level security is defined as rules that add a SQL predicate for a given role, such as a condition that matches a tenant identifier column. Metabase offers sandboxing rules that restrict a group to rows matching an attribute. In both cases, the rule is only as strong as the identity it reads. The application should take the tenant from a signed token issued by your identity provider, map it to a group or attribute on the analytics side during single sign-on, and never accept a tenant value from the browser. Confirm whether the platform's filter applies to every chart, dataset, saved question and API call, and whether it can be bypassed by users with edit rights.
- Rule definition: Keep filters in the database or semantic layer where possible, so a new dashboard cannot skip them.
- Claim flow: Map a tenant claim from the token to a session attribute, and reject sessions without one.
- Isolation tests: Run the same report as users from two tenants and compare returned row sets against an independent count.
- Operating trade-off: One schema is cheapest to run and upgrade, but a single missing filter exposes every tenant.
- Indexing: Filters on the tenant column must be indexed or every query scans all tenants.
Before go-live, ask the team which role can edit datasets and whether any path, such as raw SQL or export, runs without the filter.
With a schema or database per tenant, each customer's tables are physically separate, and the analytics layer connects to the right location for each request. Row-level filters become less central because the data boundary is structural. The main design work moves to connection management: the platform needs a way to select the correct schema from the authenticated tenant, and credentials must be scoped so one tenant's connection cannot read another's schema. This model also multiplies metadata. Datasets, dashboards and semantic definitions may need to be deployed once per tenant or generated from templates, so the team should decide early how changes roll out across dozens or hundreds of schemas.
- Rule definition: Use database roles or grants per tenant so the database itself refuses cross-schema reads.
- Claim flow: Resolve the schema name from a verified tenant claim and never build it from user input.
- Isolation tests: Attempt cross-tenant queries with each tenant's credentials and confirm the database returns permission errors.
- Operating trade-off: Stronger boundaries and easier per-tenant deletion, offset by more migrations, connection pools and backup units.
- Templating: Generate per-tenant dashboards from one source so drift between tenants is detectable.
Confirm with the vendor how the chosen platform handles per-request database selection and whether connection pooling respects tenant boundaries.
An analytics instance per customer gives each tenant its own application, metadata store, users and connections. Isolation is mostly at the deployment level, so the platform does not need complex in-application rules, but the operating burden grows with each instance. Your team owns upgrades, certificates, backups and monitoring for every one of them, and cost follows the number of instances more than the amount of data. This model suits customers with strict contractual boundaries or data residency needs. Single sign-on still matters, because each instance must trust the same identity provider and map roles correctly, and a misconfigured redirect or shared signing key can still cross the boundary.
- Rule definition: Keep instance configuration in version control so each deployment is reproducible.
- Claim flow: Bind each instance to one tenant issuer or audience and reject tokens meant for other instances.
- Isolation tests: Verify network paths, separate secrets and separate databases, then confirm a token from one instance fails on another.
- Operating trade-off: Strongest separation and simpler deletion, but the heaviest upgrade and support load.
- Automation: Provisioning and patching scripts become essential once instance counts grow.
Ask the implementation partner how instance provisioning, patch windows and secret rotation are handled and who signs off on each tenant's configuration.
How an embedded analytics rollout runs, phase by phase
The sequence moves from a tenancy decision to a supported production service, with each phase closing on evidence that the previous one holds. Isolation is tested before scale, and scale is tested before real customers see the dashboards.
Define requirements and the tenancy model
The client's product, data and security owners agree which dashboards each customer group needs, which data sources feed them, and how tenants are separated: one database per tenant, shared schemas with row-level security, or a hybrid. DeployOpen documents the chosen model, the identity provider integration for SSO, the license position for the chosen platform (Apache-2.0 for Superset, AGPL outside the enterprise directory for Metabase), and who approves each decision. The phase is complete when the requirements and tenancy decision are signed off in writing and the open questions have named owners.
Build a proof of concept on one data domain
Deploy the chosen platform in the client's own cloud account or data center, connect it to one governed data domain, and build a small set of dashboards that a real customer group would use. The proof of concept tests whether the data model, the semantic layer and the embedding method (signed guest tokens, iframe embedding or an API-driven approach) work end to end with the client's portal. It closes with a demonstration against agreed acceptance criteria and a list of gaps that must be resolved before isolation testing begins.
Test security and tenant isolation
Testers attempt to read another tenant's rows through the dashboard, filter parameters, saved questions, exports, API calls, cached results and shared links. They also verify that row-level security policies apply to every query path, that SSO sessions cannot be reused across tenants, and that administrative roles are scoped correctly. Findings are logged with reproduction steps and retested after fixes. The phase closes with a test report that records each cross-tenant attempt, its result and the retest outcome. No release proceeds to load testing while any cross-tenant read remains open.
Run performance tests at realistic concurrency
Load tests use the client's expected number of tenants, dashboard complexity and concurrent users, drawn from the usage the business has agreed to plan for. The team measures query latency, cache behavior, metadata database load and the effect of heavy dashboards on shared warehouse resources. Results inform caching strategy, query limits, warehouse sizing and whether some tenants need dedicated resources. The phase closes with recorded results against agreed response-time targets, plus a capacity model the operations team can use to predict when to add capacity.
Pilot with a small customer group
A small set of real customers or internal portal users receives access to the embedded dashboards under monitoring. DeployOpen tracks errors, slow queries, access requests that were denied, and feedback on whether the dashboards answer the questions customers actually ask. Changes made during the pilot go through the same isolation regression checks as before. The phase closes when the pilot group's issues are triaged, the defects that block general release are fixed and retested, and the client has signed off on the pilot results.
Hand over to production with runbooks
The production release is followed by a handover of the platform to the operations team, with runbooks for tenant onboarding and offboarding, access reviews, backup and restore, platform upgrades, log retention, and incident response. DeployOpen delivers the architecture record, the isolation test evidence and the configuration as documented artifacts. Support after handover is agreed separately, either as a retainer or internally. The phase is complete when the client's team has run at least one onboarding and one restore from their own runbooks and both have been witnessed and recorded.
Build in-house, use a partner or buy embedded analytics SaaS
This table compares building on open-source Apache Superset or Metabase with your own staff, delivering the same stack through an implementation partner, and buying a commercial embedded analytics SaaS. Read each row as a question to answer for your organization, then check the cost and control trade-offs against your own data residency and staffing constraints. The main takeaway is that open source moves license cost out of the picture but shifts effort, skills and recurring operation onto whoever runs the stack.
| Factor | In-house build on open source | Open source with an implementation partner | Commercial embedded analytics SaaS |
|---|---|---|---|
| Control over hosting and data residency | Full control. Dashboards, metadata and cached results stay in your accounts, regions or data centers. | Full control in your environment. The partner deploys into your cloud account or data center under a written scope. | Depends on the vendor's regions and hosting options. Confirm where query results, caches and logs are stored. |
| Licensing for embedding | Apache-2.0 for Superset. Metabase is AGPL outside its enterprise directory, so confirm obligations with counsel before embedding. | Same license position as in-house, plus the partner's review of which files and features fall under commercial terms. | Licensed per the vendor's commercial terms, usually covering embedding rights, tenants and usage tiers. Review the contract. |
| Effort to first embedded dashboard | Depends on the team's Superset or Metabase experience and on how much of the embedding and SSO work is new. | Usually shorter in calendar time because the scope, deliverables and timeline are agreed before work starts. | Often the shortest path for standard embedding, but custom tenancy or data models may need vendor services. Ask for a written plan. |
| Skills required | Data engineering, BI modeling, identity integration, Kubernetes or container operations, database administration and security review. | Partner supplies the implementation skills. Your team still needs owners for data models, access policies and business definitions. | Vendor supplies the platform skills. Your team needs product integration, data modeling and tenant administration skills. |
| Row-level security and multi-tenant access | Designed and tested by your team. Errors here are your responsibility, so plan for independent testing. | Designed with the partner and tested against written test cases. Confirm who keeps the policies current after handover. | Provided by the vendor's model. Verify how tenant isolation, row filters and token scoping are enforced and evidenced. |
| Ongoing operating burden | Upgrades, patching, backups, capacity planning, incident response and security fixes sit with your staff. | Operations can be retained with the partner under a support retainer, with upgrades and testing included in scope. | Vendor operates the platform. Your team still manages product changes, tenant lifecycle and access reviews. |
| Cost structure | Mostly one-time build effort plus recurring staff time, infrastructure and database costs. No per-user license fee for the software. | One-time implementation fee for the agreed scope, plus recurring infrastructure and any retainer for support or upgrades. | Recurring subscription or usage fees that often scale with tenants, users or queries. Ask for the pricing model in writing. |
| Exit and portability | High portability. Superset and Metabase data models and dashboards can be exported and moved with effort from your team. | Same portability as in-house, with handover documentation as a contractual deliverable. | Depends on export formats and contract terms. Confirm how dashboards, semantic models and tenant data can be exported. |
How much effort, time and cost does embedded analytics take?
What drives the total effort of an embedded analytics project?
Total effort depends mostly on how many data sources, tenants and user roles the product must serve, and on how much of the analytics experience is customized. A single internal dashboard built on one database is a small job. Embedding dashboards for many customers, each seeing only their own data, adds work in data modeling, row-level security, authentication handoff, theming and testing. Ask any partner to split the estimate into discovery, data modeling, embedding and identity integration, security testing, performance tuning, and handover, so each part can be checked against your scope.
How long does it take to get a first embedded dashboard running?
A first dashboard in a non-production environment usually comes sooner than a production-ready multi-tenant embed, because the hard parts are access control and performance at scale. The first milestone is one trusted dataset, one dashboard and one login path. The production milestone adds tenant isolation, SSO, audit logging and load testing. No timeline in this section is a commitment. Ask for a written schedule with a named milestone for each of those steps, and confirm which version of Apache Superset or Metabase the plan targets, since Apache Superset 6.1.0 (May 13, 2026) and Metabase v0.64.1 (October 7, 2026) are the releases this page was researched against.
What does the client's team need to provide?
The work needs people who own the data, not only people who build the tool. Plan for four inputs:
- A data owner who can confirm which tables, metrics and definitions are approved for customers.
- An identity owner who controls the SSO provider and can supply tenant and role claims.
- A platform or cloud engineer who provisions hosts, databases, secrets and networking.
- A product owner who decides how dashboards appear inside the application and who may change them.
If these people are not named before work starts, schedule slips are likely, because each depends on a decision from one of them.
Can our own engineers build and run embedded analytics without a partner?
Yes, many teams can, particularly if they already operate PostgreSQL or similar databases, containers and an identity provider. The risk lies in the parts that are easy to get wrong: tenant isolation at the database and semantic layer, token signing for embedded sessions, and load behavior under concurrent users. A practical test is whether your team can write and review row-level security tests, rotate signing keys and run a load test against realistic data volumes. If the answer is no for any of these, a fixed-scope implementation with knowledge transfer usually costs less than an outage or data exposure incident. Compare internal staffing and partner scope in writing before deciding.
How is row-level security tested before customers see the dashboards?
Row-level security is tested by proving that a user from tenant A cannot see any row, chart, filter value or export that belongs to tenant B. Useful checks include:
- Automated tests that query each dashboard as several test identities and compare results against an expected dataset.
- Negative tests that try filter manipulation, direct SQL access and cached-result reuse across tenants.
- Review of the embedded session token, its expiry and the claims it carries.
- Penetration testing of the embedding endpoints and the analytics application itself.
Ask the partner which of these produce repeatable evidence you can keep for an assessment, and who signs off on the results.
Which recurring costs should we expect after launch?
Recurring costs fall into four groups: hosting for the analytics application, its metadata database and caches; the data warehouse or database that serves queries, which often grows with usage; staff time for upgrades, security patches and dashboard changes; and support or retainer fees if you use an outside partner for ongoing operations. Upgrades matter because Apache Superset and Metabase both publish frequent releases, and each upgrade needs regression testing of embedded dashboards. Ask for a cost model that separates one-time implementation from monthly or annual running costs, and ask what drives each recurring line.
How does the license change the build or buy decision?
The license determines whether you can offer the platform to customers at all. Apache Superset is licensed under Apache-2.0, which generally allows embedding in a commercial product. Metabase is AGPL-licensed outside its enterprise directory, and that directory uses the Metabase Commercial License. AGPL obligations can reach your own modifications and network-accessible services, so legal review is needed before you modify or host it for customers. Confirm with counsel which edition, which directories and which embedding features your plan uses. Commercial embedded licenses from vendors may remove these questions but add a recurring fee, so include them in the comparison against build and operate costs.
Questions to ask an implementation partner before signing
Start with tenant isolation, because it is the control most likely to fail quietly. Ask the partner for the written results of cross-tenant tests: which accounts were used, whether a user in tenant A could query, export or view a dashboard, dataset or cached result belonging to tenant B, and whether those tests covered row-level security rules, dataset-level permissions and embedded guest tokens or signed embed parameters. Ask for the test scripts too, not only a summary. Then ask how they were rerun after each change to the role model, and who signed off the findings. A vague answer such as "we tested multi-tenancy" is a reason to pause.
Next, ask how the license obligations were reviewed and by whom. Apache Superset is Apache-2.0, while Metabase outside its enterprise directory is AGPL licensed, and modifying AGPL code that users reach over a network can trigger source disclosure duties. Ask whether the partner's review covered your exact deployment model, including any changes to Metabase source, any use of its enterprise directory and branding changes in an embedded portal. Ask for the written opinion and confirm your own counsel has read it. Also ask for the handover of runbooks, the upgrade approach for the chosen release (for example, how a move from one Superset or Metabase version to a later one is tested against your row-level security rules), and who holds the admin credentials for the database, the BI application and the identity provider at go-live.
Finally, ask how performance was measured and what is excluded from the fixed scope. Request the test method: the query mix, concurrency level, data volume, cache settings and the percentile targets agreed in writing, along with whether tests ran on production-sized data. Ask who owns the database and warehouse tuning after handover, since slow embedded dashboards are often a data model problem rather than an application problem. Then get the exclusions in writing: custom connectors, new data sources, additional tenants beyond the agreed count, ongoing support, and any SSO or identity provider work outside the agreed integration. Anything not on that list should be confirmed as included before you sign.
Systems the analytics platform must connect to
An embedded analytics platform is only as safe as the identities, data sources and logs around it. The cards below cover the systems that must be connected before the first dashboard reaches a customer or partner, and the access each one needs.
Identity provider for SSO
Superset and Metabase both need a federated login path, typically OIDC or SAML, so that internal analysts sign in through the corporate directory. For embedded use, the harder question is how the host application hands a user session to the analytics tool without exposing credentials. Confirm which SSO protocols each product supports in its current release, how group claims map to analytics roles, and how sessions expire when a user is deprovisioned. Ask whether signed guest tokens can carry tenant identifiers that the analytics layer enforces.
Host application authentication
The product or portal that embeds the dashboards already authenticates its customers, and that session is the real source of truth for who may see which data. The integration should issue short-lived, scoped tokens from the host backend, never from the browser, and the analytics platform should trust only those tokens. Check how the host passes tenant and role claims, what happens when a token is replayed, and whether the embedding origin is restricted. Test this path with a second tenant account before launch.
Source warehouses and databases
Every dataset the dashboards query lives in a warehouse or operational database, and the analytics service account is the most common route to cross-tenant exposure. Use a dedicated read-only role per environment, scoped to the schemas that the embedded views need, and enforce tenant filters in the database where the engine supports row-level policies. Confirm connection pooling limits, query timeouts and whether the analytics tool stores result caches, since cached results can outlive a permission change.
Data catalog for ownership
A catalog such as DataHub or OpenMetadata records which team owns each dataset, its lineage and its classification, which answers who approves a new embedded view. Without that record, dashboards accumulate on tables nobody maintains and sensitive columns reach customer-facing charts unnoticed. Confirm which connectors the catalog supports for your warehouse, whether dataset owners can be assigned to analytics assets, and how changes to upstream schemas trigger review of dependent dashboards.
Logging and SIEM
Query logs, login events, token issuance and permission changes should flow to the central logging or SIEM platform so that a tenant data exposure can be traced. Decide which events are captured by the analytics tool, which come from the host application and which come from the database audit trail, and how these are correlated by user and tenant identifiers. Confirm log retention periods with your compliance owner, and check whether query text containing customer values is written to logs in plain form.
Network and secrets paths
The analytics service needs outbound access to warehouses and inbound access only from the host application's backend and authorized administrators. Credentials for database connections and signing keys for embedded tokens belong in a secrets manager, not in configuration files. Document each network path with its port and direction, rotate signing keys on a schedule you can state, and confirm that the analytics platform's metadata database is not reachable from customer networks.
How DeployOpen scopes, builds, hands over and supports embedded analytics
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For embedded analytics, that means agreeing in writing which tenant isolation, row-level security, SSO and license decisions are in scope before any build starts.
How we scope
- Confirm whether Superset or Metabase fits the product, including the license position for your distribution and hosting model.
- Map tenants, data sources and row-level security rules that must hold for every embedded dashboard.
- Agree in writing the deliverables, timeline and acceptance tests, since most engagements are fixed-scope.
How we build
- Deploy the chosen analytics platform in your environment with SSO integration and tenant-scoped access controls.
- Test row-level security and cross-tenant data leakage with defined cases, including performance tests on representative queries.
- Customize embedding, branding and configuration within the license terms that apply to your use.
How we hand over
- Document architecture, configuration keys, access model and the tenant onboarding procedure for your operations team.
- Provide runbooks for upgrades, backups and restore tests so your staff can operate the platform after handover.
- Deliver evidence of access control and test results that your compliance team can review with independent auditors.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer, scoped separately from the build.
- Review new platform releases and licensing changes, then agree in writing which upgrades to apply and when.
- Ask any partner to confirm the retainer scope, response expectations and what is included before signing.
