How to run an embedded analytics RFP that tests isolation, licensing and load
Send every bidder the same questions, and require written answers tied to your own environment. You are sending customer-facing or portal dashboards to a partner, so the only fair comparison is one where each answer describes how the platform would run in your cloud account, against your identity provider, with your data sources. The questions in this section are neutral to vendors. They apply equally to an implementation partner building on Apache Superset, Metabase, or a commercial BI product, and they should be scored on the same scale. Apache Superset and Metabase are the two open-source options this page covers in depth, so the answers below focus on them. Ask every bidder to name the exact version they would deploy and to state which features are included in their proposal, not only in the product.
Ask for a demonstration in a staging environment rather than a slide. Give each bidder a test tenant model with at least two tenants and a user who should see only one of them, then ask them to show the row-level security rule, the guest token or SSO flow, and the logs that record who viewed what. Require them to state which features need a paid tier. For Metabase, the pricing page places SSO, row and column level permissions, and multi-tenant data segregation in the Pro and Enterprise plans, so confirm the tier in writing. Ask Superset bidders to explain how they configure OAuth2 or LDAP group mapping, because Superset has no paid edition and that work falls to the implementer.
DeployOpen does not publish prices. A quote follows from a written scope, so use this RFP to define that scope: the tenants, the number of users, the data sources, the environments, and the support model. Ask each bidder to separate one-time work (design, integration, hardening, and testing) from recurring cost (hosting, upgrades, licenses or plan fees, and support). Confirm the licensing position for distribution with counsel before the RFP closes, including how the AGPL applies if you modify Metabase and distribute it to customers. Bidders should answer that question in writing and identify any assumptions they rely on, so you can test those assumptions in the evaluation.
Row-level security and tenant isolation questions to ask
When the BI tool applies the tenant filter, isolation depends on the dashboard layer evaluating the rule on every path that returns data, including embedded frames, exports, subscriptions and API calls. In Metabase, row and column level permissions and multi-tenant data segregation are listed on the Metabase pricing page as included only in the Pro and Enterprise plans, so the partner must name the plan it prices and the feature it uses.
- Filter location: Which object carries the filter (a sandbox, a permission rule or a field filter bound to a user attribute), and does it apply to every card, question and dataset on the dashboard?
- Identifier binding: How the tenant ID is taken from the signed embedding token or JWT claim, and whether a URL parameter or client field can override it.
- Shared definitions: When one saved question or model serves many tenants, how the filter is applied per request so that results cannot leak between sessions.
- Secondary paths: How exports, scheduled emails and API endpoints inherit the same filter as the interactive view.
- Test evidence: A repeatable script that signs in as two tenants and compares row counts across dashboard, export and API.
A strong answer names the exact permission object, the claim or attribute and the plan. A weak answer says dashboards are secured by permissions without showing how the tenant value reaches the query. Confirm that the answer covers exports and subscriptions, not only the main view.
Enforcing isolation in the database or a query proxy means the tenant predicate is applied before data leaves the engine, so a misconfigured dashboard cannot widen access. Options include database row policies, views keyed to a validated session setting, or a proxy that injects and checks predicates. The ClickHouse access control documentation and its external authenticator documentation describe the building blocks, but the design still has to be specified and tested for each product.
- Enforcement point: Which database role, row policy or view applies the filter, and what the query returns if the BI service account lacks that rule.
- Identity binding: How the BI service account passes the tenant identity to the database, for example through a session setting set from a validated token, and who is allowed to change that setting.
- Proxy design: If a proxy rewrites SQL, how it parses and parameterizes queries, and how it refuses queries that carry no tenant scope.
- Pooling behavior: How connection pools reset session settings between requests so one tenant's context cannot carry into another's.
- Negative tests: Results showing that a tenant user requesting another tenant's rows receives zero rows or an explicit error.
A good answer names the policy objects, who owns them and how changes go through change control. If the partner cannot show a negative test, treat the isolation claim as unverified.
In a single-tenant deployment, each customer or business unit gets its own BI instance and database. Isolation moves largely to infrastructure, which reduces dependence on row filters inside one application but multiplies the number of instances to secure, back up and upgrade. Apache Superset, for example, requires a user-specified SECRET_KEY to start, so every instance needs its own key and a documented rotation plan.
- Instance boundary: Which components are separate for each tenant (web application, metadata database, cache, workers and the analytical database) and which are shared.
- Key management: How each instance receives its SECRET_KEY and any encryption keys, where they are stored, and how rotation uses PREVIOUS_SECRET_KEY in Superset.
- Application database: Which metadata database each instance uses, with PostgreSQL or MySQL for production as the supported choice, and how backups are scheduled per instance.
- Upgrade coordination: How the partner upgrades many instances, with backups, staging tests and a review of breaking changes before each rollout.
- Data credentials: Whether each instance has its own database user with access limited to that customer's data.
The partner should explain which of these items reduce isolation risk and which add operating load. Ask for the count of instances in the proposed design and the process for keeping them on the same version.
In a multi-tenant deployment, one BI instance serves many customers, so the filter, identity mapping and cache keys carry the whole isolation burden. Failures usually come from a missing claim that falls back to a broad default, a cache entry shared across tenants or an admin role that sees everything without a log. Metabase lists multi-tenant data segregation among the Pro and Enterprise features, and SSO mapping for JWT, OIDC or SAML is also on those plans, so the cost model must include them.
- Tenant mapping: How the tenant identifier is derived from an SSO group, JWT claim or embedding parameter, and what happens when that value is missing (access should fail closed, with no data returned).
- Cache keys: Whether cached query results and embedding sessions are keyed by tenant identity, and how a cache flush is verified.
- Shared datasets: Who can edit models or saved questions that many tenants use, and how a change is tested against every tenant scope before release.
- Administrator access: Which administrator roles can view all tenants, how that access is granted and how it is logged for review.
- Automated isolation tests: Cross-tenant tests that run on every change, with the results available to the customer's security team.
Ask the partner to run its isolation tests against a dataset that resembles production, and confirm that a failing test blocks the release.
How guest tokens and SSO embedding are implemented
How does a portal sign an embed so that Metabase or Superset trusts it?
The portal's back end issues a signed token that names the dashboard, the parameters and an expiry time, and the BI tool accepts it only if the signature verifies against a secret or key the portal holds. In Metabase, signed embedding uses a JWT built on the embedding secret key, and the token carries the filter values that restrict what the viewer sees. A good answer names the signing algorithm, states where the key is stored and how it is rotated, and shows which parameters are locked to the server side so the browser cannot change them. For Superset, ask whether the team uses guest tokens issued through the embedded SDK and how the back end builds the token. In a test environment, tamper with a parameter in the browser and confirm the request is rejected, then replay an expired token and confirm it fails.
How does the portal's identity system map to BI groups or attributes?
A good answer names the source of truth for each viewer, such as the portal's identity provider groups, claims or a customer ID, and shows the exact mapping into BI roles or filter attributes. In Superset, the configuration documentation describes mapping LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING. In Metabase, attribute and group sync for LDAP and SSO is part of the Pro and Enterprise tiers, so the answer should state which tier is priced in. Ask who owns the mapping file, how a removed user loses access, and whether a customer identifier from the token drives row-level filters. In a test environment, create users with different group memberships, change a group in the identity provider, and confirm the BI tool reflects the change on the next login.
Which login protocols does the embedded BI tool support for SSO?
The answer should list each protocol the team will use and the version of the tool that supports it. Superset is built on Flask-AppBuilder and supports OAuth2 providers such as Google and Azure, custom OAuth2 servers using the code flow, and LDAP. Metabase supports Google sign-in and LDAP in its open source and Starter plans, while JWT, OIDC and SAML with documented setups for Auth0, Entra ID, Google, Keycloak and Okta require Pro or Enterprise. Ask whether the portal logs users in through the BI tool's login page or hands off a session, and whether that session is the same one the portal uses. In a test environment, confirm that a user from an unauthorized identity provider tenant cannot reach the dashboard, and that a user removed from the portal loses access to embedded content.
How long do embed tokens and BI sessions last before they expire?
The answer should give a stated token lifetime policy, the session idle timeout and the absolute session maximum, with the reasoning behind each value. Short-lived embed tokens reduce the window in which a leaked link is useful, but they require the portal to refresh tokens without interrupting the viewer. Ask how the portal requests a new token, whether refresh happens silently, and what happens to a dashboard open in a long-running browser tab. Confirm that the vendor or team can set these values in configuration and document where they live. In a test environment, measure how long an issued token remains valid, open a dashboard after expiry, and confirm the viewer is re-authenticated rather than shown stale data.
How are embed sessions revoked when a customer leaves or a role changes?
Revocation should work at three levels: the portal stops issuing tokens, the identity provider disables the account, and the BI tool invalidates active sessions. A good answer describes which of these actions happens automatically and which needs an operator step. Ask how a signing key is rotated when a secret may have been exposed, and whether rotation invalidates tokens already in circulation. For Superset, ask how the SECRET_KEY and any PREVIOUS_SECRET_KEY rotation affect existing sessions. For Metabase, ask how deactivating a user is reflected in active embedded sessions. In a test environment, revoke one user and confirm access ends within the agreed window, then rotate the signing key and confirm old tokens are rejected.
How are public or anonymous dashboard links controlled?
Public or anonymous links should be a deliberate, reviewed exception, not a default. A good answer states which dashboards may be public, who approves them, whether the link carries a signed token or a static URL, and whether the link can be disabled without republishing the dashboard. Ask how the team confirms that no restricted filter or sensitive column appears in a public view, and how the BI tool logs anonymous access. If the content is for customers, ask whether an anonymous link ever reaches a tenant's data at all. In a test environment, open a public link from a logged-out browser, confirm only approved fields are visible, disable the link, and confirm the old URL returns an error.
What does a DeployOpen engagement cover for embed authentication, and what can the team do itself?
DeployOpen implements, customizes, integrates, hardens and documents self-hosted open-source platforms in the client's own infrastructure, and it runs security testing on applications and APIs. For this topic, that can include wiring the portal's identity provider to the BI tool, building the server-side token issuance, setting token and session policies, and testing expiry and revocation. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts, so the quote depends on how many identity sources, login protocols and embedded dashboards are in scope. A team with strong identity engineering can often build the token service itself, but it should still ask for a written test plan covering signature checks, expiry, revocation and anonymous access. Ask any partner which of these tests it runs and which evidence it hands over.
What should a test environment prove before the embed goes live?
The test environment should prove that the embed fails closed: every request without a valid, unexpired, correctly signed token is refused, and every user sees only their own data. Set up at least two test tenants with different group memberships and run the same dashboard as each. Tamper with filter parameters, reuse an expired token, remove a user from the identity provider and make a public link inaccessible. Keep the results as dated evidence, since they support later reviews by internal audit or an external assessor. Ask the team to name the owner of each test, the pass criteria and the retest trigger, such as a BI upgrade, a key rotation or a new identity provider. Note that DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications.
Which Metabase features need a paid plan
Buyers often assume that a self-hosted Metabase deployment carries the full feature set at no cost. The open source edition and the Starter plan leave several controls that a customer-facing dashboard depends on to the paid tiers, so each requirement in the RFP should be mapped to a plan before the architecture is fixed. The cards below cover the items most often assumed to be free.
Single sign-on beyond Google
Google sign-in and LDAP are available on the open source and Starter plans. Other SSO methods, including JWT, OIDC and SAML, are documented as requiring Pro or Enterprise. Ask the partner which identity provider your customers and staff use, then confirm with the vendor whether that method is covered by the plan you intend to buy. A login path that works in a test tenant may still fall outside the plan you license.
Row and column level permissions
Row and column level permissions are one of the controls that separates per-customer data access from shared dashboards. The supplied pricing information places them in the Pro and Enterprise plans only. Ask the partner to show how each customer's rows are filtered, where the filter is defined, and whether the setting depends on a plan feature. Treat any tenant isolation design that relies on this control as a plan decision, not an implementation detail.
Multi-tenant data segregation
Multi-tenant data segregation is listed as a Pro and Enterprise capability. For a SaaS product with many customers, this is the feature most likely to decide the plan. Ask the partner whether the proposed design uses one Metabase instance with segregation, separate instances per customer, or another pattern, and what each option costs in licenses and operations. Confirm the current plan terms directly with the vendor before the design is approved.
Usage analytics and auditing
Usage analytics and auditing are also restricted to the Pro and Enterprise plans. Auditors and customers may ask who viewed which dashboard and when. If audit history is a requirement, ask the partner whether a paid plan or an external logging path covers it, and what retention the design needs. Do not assume the open source edition provides an audit trail that meets your evidence requirements.
SCIM provisioning and group sync
Advanced LDAP group and attribute sync and SCIM provisioning require Pro or Enterprise. Without them, user lifecycle and group membership must be managed by hand or by a separate script. Ask the partner how joiners, movers and leavers will reach the BI tool, and whether that path depends on a paid feature. The answer determines how quickly a removed customer or employee loses dashboard access.
Enterprise pricing and quote scope
Enterprise is priced by quote starting at $20,000 per year, according to the Metabase pricing page. Starter and Pro list per-month prices, with additional user fees. Ask the partner to build the cost model from the requirements in this list, not from a plan name, and to ask Metabase for a written quote covering the features and user count you need. Confirm current pricing directly with the vendor, since plan contents and prices change over time.
How query load is kept off production databases
The first thing a good answer must establish is that dashboards should never run their heavy queries against the transactional database that runs the product. A customer-facing dashboard that refreshes many charts can hold locks, exhaust connections and slow checkout or case handling for everyone. Ask the partner to name the system the dashboards actually query: a read replica of the operational database, a separate analytics store such as ClickHouse, or the production tables directly. Only the last option should be a red flag. A replica still carries replication lag and can be expensive at scale, so ask how lag is measured and what the dashboard shows when the replica falls behind. ClickHouse, which the Superset and Metabase stacks commonly use for this role, is open source under Apache-2.0 and can be self-hosted in your own infrastructure, which keeps the analytics copy under your control.
The second layer is controls at the BI tier. Superset relies on a caching layer and, for async queries, alerts, reports and dashboard thumbnails, on Celery worker and beat processes, which the architecture documentation says most installations run with Redis and Celery. Ask how those components are sized, where the cache lives, what cache lifetimes apply to tenant-scoped dashboards so one tenant never sees another's cached result, and which query timeouts and concurrency limits are set per database connection. Scheduled extracts are the other lever: precomputed tables or nightly snapshots shift heavy aggregation to off-peak windows. Confirm whether the partner will use scheduled extracts for large customer-facing views and who owns the refresh failure runbook.
The third layer is recoverability, which the analytics copy itself needs. Replication in ClickHouse keeps replicas in sync, but it does not protect against a bad delete, a faulty transformation or corruption, because those errors replicate too. The ClickHouse backup documentation supports full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage, and it warns that a backup never test-restored will probably not restore when needed. Make restore tests part of the contract: ask for the restore procedure, the frequency of test restores on a spare cluster, the evidence each test produces, and who signs off. Also confirm the Keeper quorum design, which the replication guide recommends with at least three nodes on dedicated hosts.
How AGPL obligations apply to your product
Does the AGPL apply if we only host Metabase for our customers?
Hosting alone is not the same as distribution, and the answer turns on how your product uses Metabase. The AGPL is a copyleft license, and its network clause is the feature that matters here: it can require source availability to users who interact with a modified version over a network, even when you never ship a copy. Whether your use triggers distribution or network obligations depends on your facts, including whether you modify the code, how the dashboards are delivered and whether customers receive any part of the software. Ask your counsel to confirm the analysis for your architecture, and ask your partner to show the written license analysis before work starts.
What changes if we modify the Metabase source code?
Modifying Metabase is the fact pattern that most often raises AGPL questions, so treat it as a separate decision from hosting. If you change the open source edition and make that modified version available to users over a network, the AGPL's source-availability terms may apply to those changes. Settle this before development starts, not after release. Ask the partner to list every change, identify which ones touch the AGPL code paths, and state how they would be published or kept internal. Counsel should confirm whether separate modules or configuration alone change the result.
How do we publish changes to users who access Metabase over a network?
The publication route depends on whether the AGPL's network terms apply to your deployment, which your counsel must determine. If they do, the typical approach is to make the corresponding source of the modified program available to the users who interact with it, under the license terms. Ask the partner how the source offer would be delivered, where it would be hosted, how it would stay in sync with each release, and who maintains it. Also ask how the process handles upgrades, since each new Metabase release can alter the baseline your changes sit on.
Which Metabase edition are we using, and under what license?
The open source edition is licensed under the AGPL outside its enterprise directory. The enterprise directory uses the Metabase Commercial Software License, and the commercial editions are distributed under that license. Your edition determines which license terms apply to the code you run, so the partner should state in writing which edition, which license files and which directories are in the build. Confirm this against the repository and your order documents rather than relying on the product name. Also ask whether any features you need sit in the commercial code.
Does Apache-2.0 Superset change the AGPL analysis?
Apache Superset is licensed under Apache-2.0 and has no paid edition, so it avoids the AGPL network clause. Apache-2.0 is a permissive license, which generally lets you modify, host and distribute the software with fewer source-disclosure duties, but it still carries conditions such as license notices and attribution. A switch of tool does not remove the need for analysis. Ask the partner to confirm the license of every component in the stack, including extensions, plugins and drivers, and to record the review in the same written analysis used for Metabase.
What should the partner's written license analysis include?
The analysis should be a written document, not a verbal assurance. Ask for the license of each component, the edition and license files in use, a list of modifications, the distribution model (hosted, self-hosted by customers, or delivered as a product component), and the network interaction model. It should name the assumptions and the open questions for counsel. Ask whether the partner has a standard template and who signs off on it. DeployOpen can prepare the technical inputs and documentation for this review, but legal conclusions belong to your counsel.
Who is responsible for the licensing decision?
Your organization owns the licensing decision, with your counsel advising on the interpretation. The implementation partner is responsible for documenting the architecture, the code changes and the deployment facts that counsel needs. Ask the partner to state which decisions are theirs, which are yours, and which require legal review. Clarify who approves modifications, who tracks upstream license changes and who maintains the record after go-live. Clear ownership prevents a gap between the engineering team and the legal team.
How the partner will run upgrades, backups and support
This sequence shows how the partner will keep a self-hosted Superset or Metabase current, recoverable and supported after go-live. Each step ends with a written artifact you can check before signing, so upgrade and restore responsibilities are clear before the platform carries customer data.
Confirm the platform and deployment route
Ask the partner to state which platform and version it will deploy, and how it will install it. For Apache Superset 6.1.0, the documentation describes Kubernetes installs with the official Helm chart, while the current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. Ask which route the partner will use, why, and how it will handle the other route if the chart is later retired. Done when the answer names the install method, the version pin and the owner of the Kubernetes manifests in writing.
Define the metadata database and its backups
The partner should confirm that the metadata or application database is PostgreSQL or MySQL, not the SQLite default used by Quickstart and PyPI installs, and that the Docker Compose PostgreSQL container is not presented as production-ready. For Metabase, the application database should be PostgreSQL or MySQL rather than the embedded H2 file. Ask who takes scheduled backups of that database, where they are stored, how long they are kept, and who can restore them. Done when the runbook names the database engine and version, the backup job and the restore owner.
Rehearse upgrades in staging
Before any production change, the partner should apply the upgrade to a staging copy with representative dashboards, users, row-level security rules and embedded tokens. Ask for the staging environment to mirror production configuration, including SECRET_KEY handling for Superset and the embedding settings for Metabase. Done when the partner gives you a dated test record showing login, embedded views, scheduled reports and a sample of tenant-filtered queries working after the upgrade.
Read breaking-change notes before each upgrade
Ask the partner to review the release notes and breaking-change file for each version between the current and target release. For Superset, the upgrade documentation points to UPDATING.md for breaking changes. For Metabase, the upgrading guide recommends upgrading release by release from versions older than 40. Ask for a short written impact assessment that lists each change affecting your configuration, your custom code or your embedding. Done when every change is marked as no action, action taken or accepted risk, with a named approver.
Run the migration steps in order
For Superset, the documented steps are to back up the metadata database, run superset db upgrade, then run superset init. For Metabase, upgrades run application database migrations automatically, so the partner should take a backup of the application database first. On a clustered Metabase deployment, the partner should reduce the cluster to a single node for a major upgrade because of the migration lock, then restore the cluster after the migration completes. Done when the runbook records each command, the time it ran, the operator and the result, and the partner confirms that the health checks passed.
Prove restores with a test
A backup is not evidence of recovery until it has been restored. Ask the partner to restore the application database to a spare environment on a schedule and after each major upgrade, then open a sample dashboard and an embedded view to confirm the content and permissions returned. For ClickHouse, the backup documentation warns that a backup never test-restored will probably not restore properly, and recommends regular restore tests on spare clusters. Replication alone does not protect against human error or corruption. Done when the partner delivers a restore test record with the source backup, the target environment and the checks performed.
Agree support scope and the runbook in writing
Ask the partner which support is included in the fixed-scope engagement and which is available as a retainer for upgrades, testing and monitoring. Confirm who responds to incidents, how they are escalated to the vendor project or community, and who approves emergency upgrades for security fixes. For Metabase, the version support page lists LTS releases supported for 14 months and non-LTS releases usually reaching end of life after 2 months, so ask how the partner will track those dates. Done when the signed scope includes a runbook, an upgrade calendar, a support matrix and named responsibilities for each role.
How to score partner answers
This table sets out what a full score and a low score look like for six criteria that matter most in embedded analytics. Record each vendor's answers against the same questions so the scores can be compared directly. A partner that answers with written design, test evidence and named components should score well on every row, while vague answers about tenant isolation or licensing should be treated as a gap.
| Criterion | Full score requires | Low score looks like |
|---|---|---|
| Tenant isolation | Written design showing how row-level security or tenant filters are enforced in the database or semantic layer, with named components and a test plan that tries to read another tenant's rows | Says isolation is handled by the dashboard tool without naming where the filter lives or how it is tested |
| Identity integration | Named SSO method (OIDC, SAML, JWT or guest token), documented group or attribute mapping to roles, and a plan for who can change mappings | Mentions SSO in general terms, with no protocol, no mapping logic and no note on which features need a paid plan |
| Load isolation | Separate analytics database or replica, query limits or caching design, and monitoring of query load against production systems | Runs dashboards directly against the production transactional database with no separation or limits |
| Licensing analysis | Written analysis of the license for each component, including the AGPL position if Metabase is modified, and a list of features gated behind paid plans or enterprise licenses | Says the software is open source and free to use, without reviewing distribution, modification or hosted-service terms |
| Operations and upgrades | Documented upgrade path with metadata database backup, staging tests, migration steps and a support window for each version in use | Plans to upgrade in place with no staging environment, backup step or record of breaking changes |
| Evidence provided | Sample configuration, role mapping, test results and a list of artifacts the client receives for its own assurance files | Offers verbal assurances or a generic brochure with no artifacts to review |
Answers that should worry you in an embedded analytics RFP
A vendor or partner answer tells you as much as its product claims. The warning answers below share one pattern: they describe a control as if it exists without naming where it is enforced, how it is tested, or who pays to keep it working. Ask for the mechanism, the evidence and the owner for each.
Isolation as a dashboard filter only
If tenant separation is described as a filter applied in the dashboard, a user who edits a query or calls the query API may read other tenants' rows. Ask where row-level security is enforced: in the analytics database through per-tenant roles, row policies or a tenant-scoped connection, or only in the application layer. An answer that cannot name the database-side control is a warning sign for Embedded analytics RFP questions.
No test evidence for tenant separation
A claim that tenants are isolated is only as good as the tests behind it. Ask for the cross-tenant test cases the team runs, such as a user from tenant A requesting a dashboard, filter value or export that belongs to tenant B. Ask whether those tests run on every release and who reviews the results. Missing test evidence means the isolation has not been checked.
Guest tokens without expiry or revocation
Signed guest tokens or embedding keys that never expire, or that cannot be revoked when a customer leaves or a role changes, keep access alive long after it should end. Ask how long each token lives, how it is rotated, how a single user or tenant is cut off immediately, and how the signing secret is stored and replaced. The answer should also cover SSO-based embedding, where entitlement changes in the identity provider must reach the BI layer.
Metabase paid features described as free
Metabase's pricing page places SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing in the Pro and Enterprise plans, not in Open Source or Starter. A partner that presents those features as included in the free edition is either wrong or planning to build a workaround. Ask which plan each required feature needs and whether the quote includes that plan.
AGPL dismissed without analysis
Metabase's open source edition is licensed under the AGPL, and that license's obligations can apply when a modified version is offered to users over a network. An answer that says the AGPL does not apply, with no analysis of how the product is built, modified and delivered, leaves the distribution risk unmanaged. Ask for a written licensing analysis from counsel covering modifications, the embedding method and the commercial edition boundaries.
No plan for production query load
Dashboards that run live queries against production transactional databases can slow the systems customers depend on, especially at reporting peaks. Ask where analytical queries run, whether a replica, a warehouse or an analytics store such as ClickHouse is used, how caching and worker processes are sized, and what limits protect the source. A partner without this plan has not designed for the workload.
Backups never restore-tested
A backup that has never been restored is an assumption, not a recovery plan. Ask which databases hold dashboards, users, permissions and the analytics data, how each is backed up, and when the last full restore into a spare environment was run and timed. Replication does not protect against human error or corruption, so the answer should include point-in-time copies and restore drills.
What drives the cost and effort of an embedded analytics implementation
The cost of an embedded analytics build is split between software fees, infrastructure, and people, and only some of it is one-time. Apache Superset is licensed under Apache-2.0 and has no paid edition, so its license line is zero, but you still pay for the application server, the metadata database, and the caching and worker components that alerts, async queries and thumbnails need. Metabase is different: its open source edition is free, but SSO, row and column level permissions, multi-tenant data segregation and usage auditing sit only in the Pro and Enterprise plans. The Metabase pricing page lists Pro at $575 per month or $517.50 per month billed yearly with the first 10 users included, with $12 per additional user per month, and Enterprise is quoted from $20,000 per year. Those are recurring fees that scale with named users, which matters if your customers are the users. The analytics database, such as ClickHouse, is a separate cost with its own hosting and support lifecycle.
Effort rises fastest with three factors: the number of tenants, the complexity of your identity integration, and data volume. Each tenant adds row-level security rules, test cases and entitlement mappings that must be built and re-checked on every release. Identity work depends on whether you map OAuth groups to roles through AUTH_ROLES_MAPPING in Superset, or need JWT, OIDC or SAML in Metabase, which the pricing page places in the Pro and Enterprise plans. Large data volumes add query tuning, caching design and replication or backup work in ClickHouse. Ongoing work is recurring: Superset upgrades require a metadata database backup, superset db upgrade, superset init and staging tests, and Metabase upgrades run migrations automatically, so a backup comes first.
Ask every bidder for a written, fixed-scope quote that separates one-time work from recurring work. Request line items for discovery and architecture, tenant isolation design and testing, identity integration, embedding and theming, infrastructure sizing, backup and restore testing, upgrade support, and the license or plan fees you will pay directly to the vendor. Ask which costs are pass-through and which are included, and what changes if tenant count doubles. DeployOpen's engagements are fixed-scope and agreed in writing before work starts, so the scope document should name the tenant model, identity provider, data sources and support period. Confirm current plan prices with the vendor, since the figures above come from the pricing page at the time of research.
How DeployOpen scopes, delivers and supports embedded analytics work
This sequence takes an embedded analytics requirement from written scope to a hardened, documented and supported self-hosted deployment in the client's own infrastructure. Each step closes with an output the client can check before the next one starts.
Confirm the embedding model and tenant boundary
DeployOpen works with the client's product, security and data owners to decide who sees dashboards (staff, customers or partners), whether embedding uses signed guest tokens or SSO, and how tenants map to data. The output is a short requirements record covering the tenant identifier, the row-level rules and the identity source. Each item is confirmed in writing by the client before any build work starts, so the scope reflects what the platform must enforce rather than what the demo shows.
Agree the fixed scope and licensing position
DeployOpen issues a written scope with deliverables, responsibilities, exclusions and timelines, which most engagements use as a fixed-scope agreement. The scope records which Superset or Metabase edition is in use, which paid plan features are required, and how the license terms for distribution were reviewed with the client's legal advisers. The output is a signed scope document. Because DeployOpen does not publish a price list, the client receives a quote that follows directly from this written scope.
Size the infrastructure and isolate analytical query load
DeployOpen designs the self-hosted architecture in the client's cloud account, data center or private network, including the application database, caching and worker components and the analytical data store. Query load is kept off production systems through a read replica, a separate analytical store or a dedicated data path, with the choice recorded against the client's workload. The output is an architecture decision record and a sizing note that the client can review with its platform team.
Implement tenant isolation, SSO and row-level security
DeployOpen configures the chosen platform, wires identity through the client's SSO provider or signed embedding, and implements row-level and tenant filters at the data layer and the embedding layer. Group or attribute mapping to roles is set up, and the rules are tested against a set of named test accounts for each tenant. The output is a tested configuration where a user from one tenant cannot retrieve another tenant's rows through the dashboard, the export function or direct query paths.
Test the embedded application and its APIs
DeployOpen runs security testing against the embedded application, its APIs and the surrounding infrastructure, covering authorization, token handling, injection paths and misconfiguration. Findings are logged, prioritized and retested after fixes. The output is a test report listing what was tested, what was found, what was fixed and what remains open with an agreed reason. This testing supports the client's own assurance work but does not replace an independent audit.
Harden, back up and document the isolation controls
DeployOpen hardens the deployment, configures secret handling and backups of the application database and analytical store, and tests restores on a separate environment. It also documents the isolation controls, access roles, logging and change procedures in a form that the client's compliance team can map to its own control framework. The output is a runbook, a control description set and a tested restore record. DeployOpen prepares this evidence; independent auditors and certification bodies decide whether controls meet a given standard.
Hand over and run ongoing support
DeployOpen hands the platform to the client's operators with training on administration, upgrades and incident response. Upgrades follow the vendor's documented path: back up the metadata database, test in staging and check the release notes for breaking changes before production. Ongoing support, upgrades and continuous testing can be delivered under a retainer agreed in writing. The output is a signed handover record and, where a retainer applies, a defined support scope.
