Open-source alternative to Sisense embedded analytics

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

If your product embeds Sisense through iframes or the Compose SDK and the renewal or a hosting constraint is forcing a decision, the main self-hosted options are Apache Superset and Metabase. Apache Superset is licensed under Apache-2.0 and ships an embedded SDK that your server uses with a service account to request guest tokens from the /api/v1/security/guest_token/ endpoint, which can carry row-level security rules for each viewer. Metabase offers embedding too, but the options you can use depend on your plan: the free Open Source edition does not include SSO or row and column level permissions, and multi-tenant data segregation sits in the paid Pro and Enterprise plans. Confirm the current embedding and plan terms with Metabase before you choose, since they change.

The embedding layer is only one part of the work. Switching the viewer from a Sisense iframe to a Superset or Metabase embed does not remove the need for your application to enforce tenant isolation: your backend decides which tenant, which dataset and which rows each guest token may see, and it must do so on every request. You also own theming, so the embedded content matches your product, and identity, so that your users, their roles and any group mappings reach the analytics tool correctly through the mechanisms each platform supports. Start by inventorying which tenants, dashboards and data security rules currently exist in Sisense, because those decide how much of this work is new.

Note that neither Apache Superset nor Metabase is a vendor partner or certified provider in this context, and that DeployOpen is a Chainscore Labs company. DeployOpen plans, implements, integrates, hardens and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. Before you commit, run a short proof of concept with one embedded dashboard, one real tenant boundary test and your identity provider, and use the results to scope the rest of the migration.

Which Sisense embedding capabilities map to which open-source options

This table maps the Sisense embedding capabilities a software vendor relies on to their equivalents in Apache Superset and Metabase. Read each row as a question for your own build: what the open-source option provides, which Metabase plan it requires, and what your application must still own. The main takeaway is that Superset's guest tokens can carry tenant row rules, while Metabase's row-level permissions, SSO and tenant segregation sit in its Pro and Enterprise plans.

Capability	Apache Superset	Metabase	Gap or action
Iframe embedding	Dashboards embedded through the embedded SDK after EMBEDDED_SUPERSET is set to True	Embedding is covered in the introduction docs; confirm which embedding mode each plan includes	Test iframe host domains, cookies and content security policy in staging before go-live
Compose SDK rendering	@superset-ui/embedded-sdk renders dashboards inside your application	Confirm whether your target plan supports the SDK-style embedding you need	Rebuild custom Compose SDK widgets as Superset charts or Metabase questions
Per-tenant data filtering	Guest token requests can include row-level security rules for each embedded viewer	Row and column level permissions and multi-tenant data segregation need Pro or Enterprise	Your service must map each tenant to its rules and reject requests without a tenant scope
Theming and branding	Confirm the theming options available to the embedded SDK in your version	Confirm branding and theme options per plan in the embedding documentation	Plan styling in your front end and test any platform theming before relying on it
SSO for embedded users	Database, OAuth2 and LDAP authentication through Flask-AppBuilder; guest tokens come from a service account	Google sign-in and LDAP on Open Source and Starter; SSO needs Pro or Enterprise	Confirm whether your customers need internal logins or only signed, scoped embed access
User provisioning and group roles	AUTH_ROLES_MAPPING maps LDAP or OAuth groups to Superset roles	JWT, SAML, SCIM and advanced group sync need Pro or Enterprise	Guest viewers may not exist in your directory; confirm provisioning for your tenant model

Apache Superset or Metabase for embedded analytics: when each fits

Both tools can sit behind a host product, but they expose different embedding paths and put different features behind different licenses or plans. The right choice depends on which features your host product needs, such as per-tenant row rules, SSO, theming and how much the host team wants to build itself.

Apache Superset for code-driven embedding

Superset embeds dashboards through the @superset-ui/embedded-sdk package, which requires the EMBEDDED_SUPERSET feature flag to be set to True. Your host server requests guest tokens from /api/v1/security/guest_token/ with a service account, and those tokens can carry row-level security rules that scope what each viewer sees. Authentication for Superset's own users runs on Flask-AppBuilder with database, LDAP or OAuth2 providers. Check early whether alerts, async queries or thumbnails are needed, because those require Redis and Celery workers on top of the metadata database.

Metabase for lighter embedding with plan gates

Metabase's free Open Source edition is self-hosted with unlimited users and dashboards, and its repository ships the open source code under the AGPL. Features that a multi-tenant host usually needs, including SSO, row and column level permissions and multi-tenant data segregation, are included only in the Pro and Enterprise plans. Confirm the plan before design, because the free edition does not give you those controls. Move the embedded H2 application database to PostgreSQL before production, using the load-from-h2 command with the matching Metabase version.

Tenant isolation trade-off

Superset gives you row-level rules inside the guest token, so the host application decides the filter for each viewer on every request. Metabase's row-level permissions sit behind a paid plan, so a free deployment pushes isolation into the host application or the database views. Either way, the host team must test that one tenant cannot see another tenant's rows, using a dedicated test set of accounts for each tenant.

Identity and group mapping

Superset maps LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING, which keeps role decisions in configuration. Metabase's open source and Starter plans support Google sign-in and LDAP, while JWT, OIDC, SAML and SCIM provisioning require Pro or Enterprise. Confirm which identity provider your customers use and whether it needs a protocol that only a paid tier includes before choosing the tool.

Operations and upgrade effort

Superset's metadata database must be PostgreSQL or MySQL in production, and upgrades require a database backup, superset db upgrade, superset init and staging tests against UPDATING.md. Metabase runs its migrations automatically on upgrade, but the docs recommend a backup first and a single node for major upgrades. Ask your team who will own these routines on every release cycle, because the work recurs for as long as the product runs.

Theming and white-label scope

Plan how much branding the host product needs, such as custom colors, logos and per-customer themes, before choosing between the two tools. Confirm in each tool's current documentation which theming options exist in the edition you plan to run, since they differ by version and plan. Build a short proof of concept with one real customer view to test the embedding path before committing.

Running embedded analytics alongside the rest of the product

The simplest pattern keeps the dashboard inside an iframe on a page the host already protects. The user signs in to the host product, the host decides which dashboard to show, and the BI tool renders only what the host has authorized. Apache Superset supports this through its embedded SDK, which loads a dashboard into a host page and asks the host's backend for a token before the dashboard can load. The host keeps the login page, session cookies and navigation, so Superset never becomes a second place where customers sign in.

Session boundary: The host's session service decides whether a user may see a dashboard before any token is requested. Superset does not read the host's cookies.
Frame policy: Configure the host's content security policy to allow framing only from the Superset origin, and confirm the cross-origin cookie behavior in a test browser.
Dashboard selection: Map each host object (account, project, report) to a Superset dashboard ID on the server side, never in browser code.
Navigation: Decide how drill-through links and filters return to the host page, since the iframe has its own history.
Failure states: Define what the host shows when the BI service is down or a token request fails.

Before launch, confirm that the EMBEDDED_SUPERSET feature flag is enabled in staging and that a user without access to a dashboard cannot load it by changing an identifier in the URL.

Teams that embedded Sisense through the Compose SDK usually rebuild the same flow with Superset's SDK and guest tokens. The host's backend calls the /api/v1/security/guest_token/ endpoint using a service account, passing the dashboard and the row-level security rules for the current viewer. The backend returns a short-lived token to the browser, which passes it to the embedded SDK. The Superset service account is a privileged credential, so it should stay on the host's server, be stored in the host's secrets system and have only the permissions needed to mint guest tokens.

Token minting: Issue tokens only after the host has verified the user and resolved the tenant, and never return the service account credential to the browser.
Row-level rules: Build RLS clauses from the tenant identifier the server resolved, not from a value the client sends.
Compose SDK gap: Sisense's Compose SDK hooks and components have no direct equivalent, so the front-end chart code is rebuilt in the host's UI or as embedded dashboards.
Theming: Plan how Superset's visual options match the host's styling, since Superset does not reproduce Sisense theme settings automatically.
Key management: Set the Superset SECRET_KEY and plan its rotation with PREVIOUS_SECRET_KEY before the first production deployment.

The host team should check that the token lifetime, the RLS rules and the service account scope have each been tested with a second tenant.

How tenant isolation and identity work in the host product

With Superset, tenant isolation is only as strong as the guest tokens your host server issues. Each token carries the row-level security rules that restrict what an embedded viewer can query, and those rules are generated by your application, not by Superset. The /api/v1/security/guest_token/ call is made with a service account, so that account's privileges and the rule logic together define the tenant boundary. A wrong filter clause or an over-privileged service account can expose another customer's rows without any visible error. Before launch, confirm which roles the service account holds, keep rule generation in one reviewed code path, and decide whether each tenant gets its own dataset, schema or only a filter.

Identity in Superset comes from Flask-AppBuilder. Its OAuth2 and LDAP sign-in can map provider groups to Superset roles through AUTH_ROLES_MAPPING, so the group claims your identity provider emits become a permission model. Review that mapping as carefully as the row rules: a group that grants broader roles than intended is a leakage path that row rules will not catch. Embedded viewers normally do not sign in to Superset at all, so confirm how your product separates internal analysts from end customers and that the two never share a session or group.

Metabase handles identity and row-level permissions differently, and plan limits matter here. Per Metabase's pricing page, SSO, row and column level permissions and multi-tenant data segregation are included only in the Pro and Enterprise plans, not in Open Source or Starter, so an embedded product that relies on them needs that plan in its quote. Confirm which Metabase edition and plan your build uses, and check that the SSO setup you need (JWT, OIDC or SAML) is on that plan. Whichever tool you choose, test cross-tenant leakage in your own environment: create two tenants with distinct data, attempt direct URL and filter tampering, replay tokens across tenants, and run the same checks after every upgrade.

Moving embedded dashboards and tenant rules to the new stack

This sequence moves each embedded dashboard and its tenant data rules to the new stack in a checked order, so every customer sees the same data and styling it did on Sisense before its cutover.

Document embedding and tenant settings first
The host team lists every embedded dashboard, the iframe or Compose SDK code that loads it, the filters passed in from the host application, and the rule that maps each customer to its rows. A Sisense .dash export does not carry sharing or embedding settings, so this inventory must be written by hand from the host code and the Sisense admin console before any rebuild starts. Done means every embedded view has a named owner and a written record of how its tenant filter is applied.
Rebuild datasets and charts on the same warehouse
Analysts recreate each embedded dataset as a Superset dataset or Metabase model that queries the same warehouse tables Sisense used, rather than copying data into a new store. Where Sisense ElastiCube logic joined or transformed tables, that logic moves into SQL views or the warehouse so the number of moving parts stays visible. Done means each chart returns the same totals as the Sisense original for a sample of tenants, and the differences are recorded.
Implement the token service and row-level mapping
In Superset, the host application's server requests guest tokens from the /api/v1/security/guest_token/ endpoint using a service account, and each request carries row-level security rules that restrict what the viewer can see. The EMBEDDED_SUPERSET feature flag must be set to True for this to work. In Metabase, the host signs embedding tokens with the parameters that filter each tenant's data. Done means a request for one tenant returns no rows belonging to another, verified with a test account.
Theme the embedded views
The product team maps the host application's colors, fonts and logo onto the new embedded views and checks that each chart remains legible inside the host layout and on the sizes the customers use. Superset and Metabase each expose their own theming options, so the team confirms in the current documentation which settings can be applied to embedded content and which must stay at the tool level. Done means a reviewer signs off on screenshots for each embedded page against the agreed design.
Configure identity and group mapping
Identity work connects the host's login to the BI tool. Superset supports database, LDAP and OAuth2 authentication through Flask-AppBuilder and can map LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING. For Metabase, confirm with the vendor whether the needed SSO method is included in the plan the team will buy, since JWT and SAML are listed on Pro and Enterprise plans. Done means each test user lands on the correct dashboards with the correct role.
Run tenant isolation tests
Security testers attempt to read one tenant's data while signed in as another, alter tenant identifiers in token requests, and check that exported files and cached results respect the same rules. The test cases are written down, run against staging with the production data shape, and repeated after every upgrade. Done means every case has a recorded result, and any failure blocks the cutover of that tenant until it is fixed and retested.
Cut over tenant by tenant
The team moves one tenant or a small group at a time, keeps the Sisense view available as a fallback for that group, and confirms with the customer that numbers match before retiring the old view. Back up the metadata database before each change, and in Superset run the documented database upgrade and init steps when versions change. Done means each tenant has a signed-off date, and the Sisense embed for that tenant is removed only after the agreed check passes.

Questions host-product teams ask before replacing Sisense embedding

What does it cost to replace Sisense embedding with open source?

The license fee for Apache Superset is zero, but the work is not free. Cost comes from four places: the engineering time to build the host-side embedding service and guest token flow, the infrastructure for the metadata database, caching and workers, the migration of dashboards and data security rules, and the ongoing upgrades and on-call support. Apache Superset is licensed under Apache-2.0 and has no paid edition, so the license line on a quote is nothing. Metabase's free Open Source edition has no license fee either, but SSO and row and column level permissions require a paid plan, and its embedding and multi-tenant features are tied to the plan you choose. Ask any vendor, including DeployOpen, for a quote that lists each component separately, and ask which items recur every year.

How long does an embedding migration take?

Duration depends mainly on tenant count, the number of embedded dashboards, how many data sources each one reads, and how much row-level logic must be rebuilt. No supplied figure gives a standard timeline, so treat any number you hear as unverified until it is tied to a written scope. A useful first step is an inventory of dashboards, datasets and tenant rules, because that inventory sets the size of the work. Expect the host-side identity and tenant isolation work to take as long as the dashboards themselves. Most engagements are fixed-scope, so ask for deliverables and milestones in writing before work starts.

What must our team provide for the migration?

Plan to supply four things: engineers who own the host application's server code, an identity provider the host already trusts, read access to the warehouse or databases that feed the dashboards, and someone who can approve tenant and security rules. The host server requests guest tokens from the Superset endpoint with a service account, so your engineers must build that path and decide which claims carry tenant identity into row-level security rules. Superset's architecture also requires a metadata database, and optional caching and Celery workers for async queries, alerts and thumbnails, so someone must operate those. Confirm each dependency with your own environment before scoping.

Can our own team do the replacement without an outside partner?

Yes, if your team has engineers who can run Flask-based services, manage PostgreSQL, and handle identity configuration. Superset documents its embedding flow, guest tokens and configuration keys, so a capable team can build the work in-house. The harder parts are usually tenant isolation, theming and the upgrade routine, which means backing up the metadata database, running the database upgrade and initialization commands, testing in staging, and checking the upgrade notes for breaking changes between versions. Decide early whether that ongoing work will sit with your staff or with a retainer. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your infrastructure, and offers ongoing support as a retainer.

Should we choose Metabase or Apache Superset for SSO and row-level rules?

Choose by which access controls you need to enforce inside the embed. Apache Superset supports database, LDAP and OAuth authentication through Flask AppBuilder, maps LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING, and accepts row-level security rules in guest token requests, so the rules are set by your server at token time. Metabase's free Open Source edition does not include SSO or row and column level permissions. Those features, along with JWT, OIDC and SAML, require the Pro or Enterprise plan, and the Pro plan price is listed on Metabase's pricing page. If your host needs signed, per-request tenant rules and can build the token service, Superset fits well. If you need built-in permissions with fewer custom services and can budget for a paid plan, Metabase may be the better match. Confirm the feature list against the current plan page before deciding.

What breaks most often in a Sisense-to-open-source embedding move?

The most common failures are in tenant isolation and access rules, not in charts. A dashboard may render correctly while a tenant sees rows it should not, so test row-level rules with multiple tenant accounts before launch. Other frequent problems include theming that does not match the host, session handling in iframes, and identity claims that map to the wrong roles. Superset also requires a user-specified SECRET_KEY to start and supports rotating it with PREVIOUS_SECRET_KEY, so plan key management from the start. Build a test matrix that covers each tenant, role and dashboard, and keep it in version control so upgrades can be rechecked.

What should we ask a vendor before signing a migration scope?

Ask for a written scope that lists tenants, dashboards, datasets, identity integrations and the security rules to be rebuilt, plus the deliverables and acceptance tests for each. Ask how the vendor will test tenant isolation and what evidence it will hand over. Ask who operates the platform after launch, how upgrades are scheduled and tested, and what backup routine covers the metadata database. Request separate line items for implementation, migration, support and any retainer, so you can see what recurs. Also ask how the vendor will prepare compliance evidence. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the reports.

What the replacement costs in components, not list prices

The main cost difference is that Apache Superset carries no license fee, because the project is Apache-2.0 licensed and has no paid edition. Metabase is different: its free Open Source edition is self-hosted with unlimited users, but the Pro plan's list price for SSO and row-level permissions is published on its pricing page, and Enterprise is quoted by sales starting at $20,000 per year. Embedded products usually need per-tenant row-level rules and SSO, so confirm with Metabase which plan covers the features your embedding design depends on before you budget. Whatever you choose, the remaining costs sit in the components you run and the people who build them.

Expect these recurring and one-time categories. One-time work includes building the guest token service that your server runs against /api/v1/security/guest_token/, theming the embedded dashboards, and designing tenant isolation. Recurring work includes the metadata database, the Redis and Celery workers that alerts, async queries and thumbnails need, staging environments, and the upgrade cycle: backing up the metadata database, running superset db upgrade and superset init, and reading UPDATING.md for each release. Metabase upgrades run application database migrations automatically, so plan a backup and a single-node window for major versions. Security testing of tenant isolation is a separate cost you should budget for on every significant change to row-level rules.

When you ask for a quote, request each component separately: infrastructure sizing for the application, metadata database, caching and workers; the engineering hours for the token service, theming and identity mapping; the tenant isolation test scope and retest frequency; and the upgrade and support model, including whether it is a fixed-scope project or a retainer. Ask the vendor or partner to name which features sit on which Metabase plan and which Superset release line they will support. Confirm the current Superset and Metabase support windows in their own documentation, since those dates change between releases.

How DeployOpen scopes and delivers embedded analytics replacement

The sequence moves from a written scope to a tested, documented embedded analytics setup in your own infrastructure, with tenant isolation, identity and theming checked before any customer sees a dashboard. Each step ends with a named output that you can review and accept.

Agree a written scope and deliverables
Before any work starts, DeployOpen and your team list the embedded surfaces to replace, the tenants and roles that must be isolated, the data sources each dashboard reads, and the identity provider that signs users in. The scope also states which Sisense features are being retired, such as ElastiCube models or BloX actions, and which are being rebuilt on Superset or Metabase. The output is a signed statement of work with deliverables, acceptance criteria and a timeline agreed in writing. Ask for the list of excluded items in writing so the boundary is clear.
Review tenant isolation and identity design
DeployOpen reviews how your host application will request guest tokens from the Superset guest token endpoint, or how Metabase embedding will sign requests, and how row-level rules map each tenant to its data. The review covers which service account the host server uses, whether the signing secret stays on the server, and how user, group and role mapping works through the authentication options of the chosen tool. For Metabase, the review also checks whether the required SSO, row and column permissions and multi-tenant segregation are included in the plan you have selected. The output is a written architecture decision record that your security team can approve.
Stand up the analytics platform in your infrastructure
DeployOpen installs the chosen platform in your cloud account, data center or air-gapped network, with a production metadata database rather than the SQLite or embedded H2 defaults, and with the caching and worker components required for async queries and scheduled reports where needed. Secrets such as the Superset SECRET_KEY are set and stored in your secrets manager. The output is a working staging environment, a runbook of components and configuration keys, and a recorded list of versions in use, so you can confirm what you are running.
Rebuild dashboards and apply theming
Dashboards are recreated against the same warehouse or database tables that feed Sisense today, with query logic moved out of ElastiCube models where the source is a database. DeployOpen applies your brand theme, fonts and colors to the embedded views, and configures the embedding SDK or iframe settings in your host application. Where a Sisense BloX action or custom sharing rule has no direct equivalent, the gap is logged and reviewed with you before it is built. The output is a dashboard inventory mapped one to one to the source Sisense items, with each gap marked as rebuilt, redesigned or dropped by agreement.
Test tenant boundaries and embedded access
DeployOpen runs security testing against the tenant boundary: tokens issued for one tenant are checked against data from another, expired or altered tokens are rejected, and row-level rules are exercised from the embedded viewer role and from direct platform logins. Session handling, token lifetime, and the rights of the service account are reviewed. Findings are rated, reported with reproduction steps, and retested after fixes. The output is a test report with the findings closed or accepted in writing by your owner of the risk. Note that this testing is a security assessment and is separate from any independent audit or certification.
Document, back up and hand over
DeployOpen writes the operating documentation: architecture, tenant and identity configuration, backup and restore procedures for the application database, and the upgrade path that follows the vendor's documented steps, including backing up the metadata database and testing in staging before each upgrade. Your team is trained on administering the platform and rotating secrets. The output is a handover pack and a restore test result. For compliance programs, DeployOpen also collects the configuration and access evidence your auditor will ask for, but the audit report itself is issued by an independent auditor or certification body.
Run production cutover and optional retainer support
The embedded views are switched from Sisense to the new platform in agreed phases, with the old iframes or SDK calls kept available until your sign-off. After cutover, DeployOpen monitors the first period of production use against the acceptance criteria. Ongoing support, version upgrades, and continuous security testing can be placed under a retainer, scoped in writing. The output is a signed cutover record and, if chosen, a retainer agreement that states the services and response expectations explicitly.

Open-source alternative to Sisense embedded analytics