Which fits: Sisense or Metabase for a lighter self-hosted BI layer?
Metabase fits a lighter self-hosted BI layer, and Sisense fits when the work is heavy modeling or deep embedding. If your renewal is driving the review and most of your users ask questions of tables they already have in PostgreSQL or a warehouse, Metabase is the smaller footprint: a single JAR or container, an application database in PostgreSQL, and a free Open Source edition with unlimited users and dashboards. Self-service questions and dashboards are the core of that edition. Sisense fits better where ElastiCube modeling is central to how your analysts work, where you already run Kubernetes and can staff it, or where embedding is a large part of the product and needs the more extensive options Sisense offers.
The decision then turns on three checks. First, identity and row-level control: SSO (including SAML and OIDC), row and column level permissions, and usage auditing sit in Metabase's Pro and Enterprise plans, not in Open Source or Starter, so confirm the plan you need against your current Sisense data security rules before you commit. Second, embedding: if customers or partners see dashboards inside your product, check whether Metabase's embedding options under the plan you would buy cover your tenant model, theming and identity needs. Third, the dashboards themselves: inventory how many Sisense dashboards depend on ElastiCube logic that Metabase handles differently, such as complex calculated measures or BloX actions, because those are the items that take real rebuild time.
Before you choose, ask Metabase for the current plan terms in writing and test the two highest-risk dashboards in a staging instance. Confirm whether your data residency requirement allows the Open Source edition to meet your authentication model, or whether the paid plan is needed from day one. If the answer is Metabase, the Metabase pricing page lists the plan limits to compare against your user count and access rules. If the answer is Sisense, weigh the quoted subscription and Kubernetes footprint against the self-hosted Superset option before deciding.
Which scenarios favor Metabase and which favor Sisense
This table maps common Sisense replacement scenarios to the better fit between Metabase and Sisense, along with the condition that decides it. Read each row against your team size, identity requirements, hosting constraints and data model. Metabase's SSO, SAML and row-level permissions sit in the Pro or Enterprise plans, so budget for that tier wherever those controls are required.
| Scenario | Better fit | Condition that drives it |
|---|---|---|
| Small analytics team with internal dashboards | Metabase | Open Source edition is free to self-host, with unlimited users and dashboards |
| Team that needs SSO or SAML sign-in | Metabase Pro or Enterprise | SAML, JWT, OIDC and SCIM require Pro or Enterprise. Open Source and Starter do not include them. |
| Team that needs row-level permissions | Metabase Pro or Enterprise | Row and column level permissions are included only in Pro and Enterprise plans |
| Customer-facing embedded analytics | Confirm with both vendors | Test tenant isolation, theming and identity work against each product. Metabase's multi-tenant data segregation is also Pro or Enterprise. |
| Ops team that wants to avoid Kubernetes | Metabase | Metabase runs as a JAR or container with PostgreSQL. On-premises Sisense is deployed on Kubernetes. |
| Heavy multi-source data modeling | Sisense, after a proof of concept | Test ElastiCube-style modeling against your sources. Metabase queries connected databases directly, so complex models may need warehouse-side work. |
| Air-gapped or fully isolated network | Metabase Enterprise | Only the Enterprise plan offers air-gapped deployment. Confirm Sisense's options with the vendor. |
| Large existing Sisense estate | Neither, until inventoried | Inventory ElastiCubes, dashboards and data security rules first, since both options require a rebuild |
What a Metabase deployment looks like next to Sisense on Kubernetes
Metabase runs as a single JAR or as a container image, and its main operational dependency is an application database that stores users, dashboards, questions and settings. The application database should be PostgreSQL in production. Metabase ships with an embedded H2 database, which suits demos and evaluation but should not hold your production metadata. MySQL 8.4.0 or MariaDB 10.6.0 and later (with utf8mb4) are also supported if PostgreSQL is not an option for your team. For a proof of concept, a single container and a managed or self-run PostgreSQL instance is the whole footprint, and you can review the steps in the Metabase application database documentation.
Sisense is typically deployed as software on Kubernetes, which means the platform is a set of services that your team must schedule, scale, upgrade and monitor inside a cluster. That is a real operating commitment, and it is the main reason a lighter Metabase footprint can matter. Confirm the current hardware and node minimums for your Sisense version with Sisense before you size the comparison, because published minimums change between releases. On the Metabase side, confirm the container resources, the PostgreSQL sizing for your number of dashboards and the number of nodes you intend to run.
The lighter footprint matters most when your team lacks Kubernetes operators, or when no one on the team already runs stateful workloads on a cluster. If you have a platform team that already operates Kubernetes well, the difference in infrastructure may matter less than the difference in upgrade and backup work, which is covered elsewhere on this page. Ask a short set of questions: who will patch the cluster, who owns the application database backups, and where the Metabase container will run during a major upgrade, since Metabase recommends reducing a cluster to a single node for major upgrades because of a migration lock.
Where the data and metadata live with each option
Both options keep dashboards and query data inside the client's infrastructure only if the deployment is set up that way, so the choice comes down to where the application database sits, which identity features the plan includes, and which Sisense deployment model is in use today. The cards below list the checks that matter before any migration plan is signed off.
Metabase data stays where you host it
A self-hosted Metabase runs as a JAR or container in your own environment and queries your databases directly. Metabase's own metadata, including users, questions and dashboards, lives in the application database, which the docs recommend running on PostgreSQL for production rather than the embedded H2 database. Confirm which hosting account, network zone and backup location will hold that application database before any data is loaded.
Open Source edition is self-hosted
The free Open Source edition is self-hosted by design, with unlimited users and dashboards, so there is no vendor cloud in the data path. Confirm that your internal policy accepts running that edition without vendor support, and that your team has an owner for upgrades, patching and backups of the application database.
Air-gapped deployment needs Enterprise
Metabase's pricing page states that only the Enterprise plan offers air-gapped deployment. If your network must have no outbound path at all, the Open Source edition alone does not meet that requirement, and the Enterprise quote, which starts at $20,000 per year, becomes part of the comparison. Ask Metabase in writing which features would be unavailable in a disconnected network.
Identity features depend on the plan
Google sign-in and LDAP are available on Open Source and Starter, while JWT, OIDC, SAML, advanced LDAP group and attribute sync and SCIM provisioning require Pro or Enterprise. Map each identity requirement from your current Sisense setup, such as directory groups that drive data access, against this list before you choose a plan. Documented SAML setups cover Auth0, Entra ID, Google, Keycloak and Okta.
Confirm Sisense deployment models
Sisense is offered as SaaS, dedicated cloud or on-premises software on Kubernetes, so the data location in your current setup depends on which model you bought. Confirm with Sisense which model you run, where its ElastiCube data and metadata are stored, and whether any component is hosted by Sisense. That answer determines what you must export, secure and retain during the move.
Compliance evidence, not compliance claims
Where data and metadata sit affects which controls an assessor will examine, such as access control, logging, backup and change management for the application database. DeployOpen can prepare configurations, runbooks and evidence for that review, but independent auditors and certification bodies decide whether the controls meet the standard. Ask your assessor which evidence they expect from a self-hosted BI tool before the design is final.
Embedding options by Metabase plan
If your analytics are consumed only by employees, the free Open Source edition covers most of the core need. It is self-hosted with unlimited users and dashboards, so you do not pay per seat to give staff access. The main design work is in the identity and access setup, since the features that tie logins to central directories sit on higher plans.
- No license fee for staff access: Open Source allows unlimited users and dashboards, so internal rollout cost is driven by hosting and administration rather than seats.
- Built-in and Google sign-in: Open Source and Starter support Google sign-in and LDAP, which may be enough for a small workforce.
- Gaps to plan for: SSO through SAML or OIDC, SCIM provisioning and row and column permissions are not on the free tier, so confirm whether your directory policy requires them.
- Permission model: Without row-level rules, you separate data through database views or separate collections, and you should document that workaround before rollout.
Before you commit, ask your directory team whether LDAP and Google sign-in meet your access policy, and confirm that the permission approach you chose does not depend on a paid feature.
Embedding dashboards inside your own product means Metabase handles the analytics surface while your application handles who sees what. Metabase's embedding documentation describes this model, and the plan you choose determines which identity methods you can use. Starter includes the basic sign-in methods, while JWT, OIDC and SAML arrive with Pro, so a customer-facing product usually needs the Pro tier for single sign-on from its own identity provider.
- Identity methods by tier: JWT, OIDC, SAML (with documented setups for Auth0, Entra ID, Google, Keycloak and Okta) and SCIM provisioning require Pro or Enterprise.
- Tenant isolation: Row-level permissions and multi-tenant data segregation are included only in Pro and Enterprise, so tenant boundaries should be enforced in the Metabase configuration, not only in your UI.
- Usage analytics and auditing: These are also Pro and Enterprise features, which matter if you must show per-tenant usage.
- Per-user pricing on Pro: Pro costs more per month and the first 10 users are included, with additional users charged per month, so a large external user base changes the math.
- Theming and branding: Your team owns the look and feel, the session handling and the tenant mapping in the host application.
Ask Metabase which embedding authentication method fits your architecture and whether the Pro features cover your tenant model before you design the host integration.
Enterprise is the tier for organizations that need air-gapped deployment, which the other plans do not offer. This matters in regulated or classified networks where the analytics platform cannot reach external license or update services. Enterprise pricing is set by quote, and the pricing page lists it starting at $20,000 per year, so treat that as a starting point rather than a final figure.
- Air-gapped deployment: Only the Enterprise plan includes it, so networks without outbound access need this tier from the start.
- Quoted pricing: Enterprise is priced by quote, starting at $20,000 per year according to the Metabase pricing page.
- Operational ownership: Your team still runs upgrades, backups and monitoring of the application database, which Metabase documents as automatic migrations that need a backup first.
- Compliance evidence: Metabase's features do not certify your control environment, so audit evidence for access reviews must come from your own logs and configuration.
- Separate enterprise image: Enterprise runs from a separate image from the open-source one, so confirm the deployment artifacts before building your pipeline.
Confirm with Metabase whether the Enterprise terms and air-gapped support cover your network model, and ask for the quote in writing with the exact deployment assumptions.
Sisense's Compose SDK follows a different model from Metabase embedding, so compare the two directly rather than assuming a like-for-like swap. The difference lies in where the application logic sits and how much of the front end the SDK provides. Read Metabase's embedding introduction to see its approach in full before you map your current integration onto it.
- Model differences: Verify whether your Sisense Compose SDK integration relies on components, data security rules or ElastiCube behavior that has no direct Metabase equivalent.
- Identity mapping: Document how your current tenant and user identities flow into Sisense, then decide how they map to Metabase sign-in on your chosen plan.
- Theming work: Measure how much styling and layout your team has built around the SDK, since that effort moves to your application.
- Tenant isolation work: Confirm which isolation checks your host product must now enforce itself.
- Test coverage: Build tests for each tenant scenario before cutover, using a non-production instance.
Run a proof of concept against one embedded dashboard and one tenant before you commit to a plan, and use the embedding introduction as the reference for each integration decision.
What moves cleanly from Sisense dashboards to Metabase
Sisense dashboards are rebuilt in Metabase, not imported. Plan the work as a rebuild against the same source databases, not as a file conversion. Sisense .dash exports describe widgets, filters and layout in Sisense terms, and Metabase has no equivalent import path for them, so budget for each dashboard to be recreated as Metabase questions, dashboards and filters. Any tooling that claims automated conversion should be tested on one of your own dashboards before anyone relies on it. Confirm the current Metabase import options with Metabase directly before you rely on any of them.
ElastiCube logic has to be re-expressed in the warehouse or in Metabase. An ElastiCube combines tables, joins, calculated columns and in-memory aggregation. In Metabase, that logic becomes SQL in native questions, joined tables and calculated columns in the query builder, or, preferably, views and tables created in PostgreSQL or the analytical database you already use. Moving the transformations into the database makes them reviewable, testable and reusable by every dashboard. Ask who owns each cube's business rules today, because that person must sign off on the rebuilt definitions.
Inventory before you rebuild. Export a list of dashboards and their filters, record which ElastiCubes each one depends on, and pull the data security rules and the groups that apply them from Sisense. Map each Sisense group to a Metabase group and check which row and column level permissions you need, because those controls require the Pro or Enterprise plan under the Metabase pricing page. Treat dashboards that nobody has opened in months as candidates to retire rather than rebuild. Sharing settings and BloX actions also need separate decisions, since they do not carry over as part of the dashboard itself.
What each option costs to run, and what drives it
Sisense pricing is quoted by sales, so the comparison turns on which components each quote includes. Metabase splits its costs more visibly between a free edition, paid plans priced per month, and an Enterprise tier quoted by sales. Use the cards below to see who is paid for what, what recurs, and what to ask for before you compare totals.
Sisense license or subscription
Sisense is sold as SaaS, dedicated cloud, or self-managed software, and the license price is set by a sales quote rather than a public list. Ask whether the quote is annual or multi-year, which deployment model it covers, how users and data volume are counted, and whether support and upgrades are included. This is the largest recurring line item to compare against Metabase.
Kubernetes and storage infrastructure
Self-managed Sisense runs on Kubernetes, and its storage and compute needs drive hosting cost, including the fast storage its data models use. Ask the vendor for hardware minimums in writing, then price nodes, storage, backups and monitoring in your own cloud account. Metabase needs a JVM host and an application database, which usually fits on much smaller infrastructure.
Metabase Open Source at no license fee
The open-source edition has no license fee and allows unlimited users and dashboards when self-hosted. Your recurring costs are then infrastructure, the PostgreSQL application database, and staff time for upgrades and backups. Confirm which features you need, because SSO, row and column level permissions, and usage auditing are not part of Open Source.
Metabase Starter and Pro subscriptions
Starter is $100 per month, or $90 per month billed yearly, with 5 users included, and Pro is $575 per month, or $517.50 per month billed yearly, with 10 users included, according to Metabase's pricing page. Additional users cost $6 per month on Starter and $12 per month on Pro. Count your named users and check which identity features each tier unlocks before choosing a plan.
Enterprise plan and air-gapped needs
The Enterprise plan is priced by quote starting at $20,000 per year, and it is the only plan that offers air-gapped deployment. If your network is isolated, this is the cost line to compare, not the Starter or Pro list price. Ask the vendor for the scope of support, the deployment assistance included, and any term conditions in writing.
Implementation, migration and staff time
One-time costs include rebuilding dashboards, mapping Sisense groups and data security rules to Metabase permissions, and migrating the application database. Recurring costs include the people who run upgrades, backups and access reviews. Ask any implementation partner for a fixed scope, named deliverables and the internal hours your team must commit, so both options carry the same staff assumptions.
How a move from Sisense to Metabase proceeds
The sequence turns Sisense dashboards, data models and access rules into a Metabase deployment on PostgreSQL that runs beside Sisense until users confirm the results match. Each step ends with a check the team can verify before moving on.
Inventory dashboards, ElastiCubes and security rules
The team lists every Sisense dashboard, widget and filter in use, every ElastiCube and the source connections behind it, and every data security rule and group assignment. Analysts confirm which dashboards are still used, since usage often differs from what the export shows. The output is a signed-off inventory with one row per dashboard, its source tables and its owner. The step is done when each dashboard has a named owner and a list of the tables it reads from.
Provision PostgreSQL and the Metabase application
The platform team deploys Metabase from the open-source image or JAR in its own infrastructure and provisions a PostgreSQL instance for the application database. Metabase recommends PostgreSQL for production, while its embedded H2 database is meant for demos. The team confirms backup schedules and access controls for the PostgreSQL instance before any content is loaded. The step is done when Metabase starts, connects to PostgreSQL and passes a basic login test.
Connect Metabase to the same source databases
Engineers add the warehouse or operational databases that Sisense queried as data sources in Metabase, using read-only database accounts. Where an ElastiCube combined several sources or held transformed data, the team recreates that logic as views or queries in the source database, since Metabase queries sources directly. Analysts check that row counts and key totals match the Sisense figures for a sample of reports. The step is done when each source returns the same results as the matching Sisense query.
Rebuild dashboards and map groups to permissions
Analysts rebuild the inventoried dashboards as Metabase questions and dashboards, starting with those used most, and the team maps each Sisense group to a Metabase group with collection permissions. Data security rules that restrict rows or columns are documented separately because they depend on the plan chosen in the next step. Reviewers compare each rebuilt dashboard against the Sisense original for filters, definitions and totals. The step is done when every retained dashboard has a reviewed counterpart and each group has written access rules.
Choose the plan for SSO and row-level rules
Before go-live, the team checks which features its access model requires. SSO through JWT, OIDC or SAML, advanced LDAP group sync and SCIM provisioning, and row and column level permissions are listed on the Metabase pricing page as Pro or Enterprise features, while Google sign-in and basic LDAP are available on Open Source and Starter. Leadership or procurement requests a written quote for the chosen plan from Metabase, and the team confirms the current terms with the vendor. The step is done when the plan is selected and every access rule from the inventory is mapped to a supported feature.
Back up and set up the H2 to PostgreSQL load
If any test instance used the embedded H2 database, the team loads it into PostgreSQL with Metabase's one-time load-from-h2 command. The command must run with the same Metabase version that last updated the H2 file, so the team checks the version before running it. Before any upgrade, the team backs up the application database, since Metabase runs application database migrations automatically at startup. The step is done when the load completes, the record counts match and a tested backup exists for the target version.
Run in parallel and cut over
Sisense and Metabase run side by side for a period agreed with the business owners, and users check their key reports against both tools. Discrepancies go back to the rebuild step until the owners sign off. The team then redirects links, retires Sisense access in stages and keeps the final Sisense export archived for reference. The step is done when owners have signed off every retained dashboard and the cutover plan, rollback steps and archive location are documented.
Questions buyers ask before switching from Sisense to Metabase
Can our team migrate from Sisense to Metabase without outside help?
Yes, a team with database and BI administration skills can rebuild dashboards in Metabase on its own, and many do. The work is rebuilding questions and dashboards against the same databases, mapping Sisense groups and data security rules to Metabase permissions, and standing up the application database. Teams without a Kubernetes or PostgreSQL operator, or with many dashboards and complex ElastiCube models, often find outside help useful for scoping and rebuilding. Start by inventorying your Sisense dashboards, ElastiCubes and data security rules so you know what you are rebuilding. Confirm the details against your own environment before committing.
What work does a Sisense to Metabase migration need from our team?
The work falls into a few parts that your team should plan for:
- Inventory: list dashboards, the data sources behind them, and who can see what in Sisense.
- Data access: confirm Metabase can connect to the same warehouses and databases, with the drivers and network access it needs.
- Rebuild: recreate questions and dashboards, and check filters and calculations against the source data.
- Permissions: map Sisense groups and data security to Metabase groups, and decide whether row and column rules need a paid plan.
- Application database: run Metabase on PostgreSQL for production rather than the embedded H2 database.
Each part needs named owners in your team, and each depends on how many dashboards you have.
How long does a Sisense to Metabase migration take?
The timeline depends on dashboard count, the number of data sources, how complex your Sisense ElastiCube models are, and how much permission logic must be rebuilt. Because these factors vary widely, no fixed duration applies to every team. A practical way to estimate is to count dashboards and data sources from your inventory, then pilot a few representative dashboards to measure rebuild effort. Ask any implementation partner for a fixed-scope plan with agreed deliverables and dates in writing before work starts.
Which Metabase plan do we need for SSO and row-level permissions?
Single sign-on and row and column level permissions are included only in the Pro and Enterprise plans, according to Metabase's pricing page. The Open Source and Starter plans do not include them. Starter supports Google sign-in and LDAP, while SAML, OIDC, JWT and SCIM provisioning require Pro or Enterprise. Confirm current plan contents on the Metabase pricing page before you decide, because plan features can change.
How do Metabase upgrades and LTS support work?
Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months, according to Metabase's version support page. Upgrades run application database migrations automatically, so Metabase recommends backing up the application database first. For major upgrades, reduce a cluster to a single node because of a migration lock, and upgrade one release at a time if you are coming from a version older than 40. Plan a regular upgrade window and choose between LTS and non-LTS releases based on how often you can test.
What drives the cost of moving from Sisense to Metabase up or down?
Costs fall into one-time and recurring groups. One-time costs include inventory, rebuilding dashboards, permission mapping, testing and any implementation help. Recurring costs include hosting Metabase and PostgreSQL, backups, upgrades, and any paid Metabase plan with its per-user fees. The Open Source edition has no license fee, and Starter and Pro list per-month prices with user allowances on Metabase's pricing page. Costs rise with dashboard count, the number of users needing SSO or row-level rules, and the number of integrations. Ask any quote for each component separately, including who runs upgrades after go-live.
Can Metabase replace Sisense embedded analytics in our product?
Metabase offers embedding options, and its embedding documentation describes how to embed dashboards and questions in your application. Whether it fits depends on how your product uses Sisense today, including iframes or the Compose SDK, tenant isolation, theming and how your identity flows map to Metabase. Embedding features and their plan requirements can differ by Metabase edition, so check the Metabase embedding introduction and the pricing page against your requirements. Treat embedding as a separate scoping exercise from internal dashboards.
How DeployOpen helps evaluate and implement a Metabase move
DeployOpen plans and implements self-hosted Metabase inside your own cloud account, data center or air-gapped network, and starts every engagement with a written scope that names the deliverables, the Sisense inventory it covers and the timelines agreed before any work begins. In the evaluation phase we review the Sisense ElastiCube and data security inventory against the databases Metabase will query, decide which dashboards are rebuilt and which are retired, and confirm which Metabase edition covers the features you actually need. Because SSO, row and column level permissions and usage auditing sit only in the Pro and Enterprise plans, that edition decision is a budget and risk decision, and we document it in the scope so it is not discovered during cutover.
On the implementation side, we deploy Metabase from the container or JAR you choose, move the application database off the embedded H2 file to PostgreSQL using the documented migration path, and set up the upgrade runbook, including a database backup before each migration and the single-node step for major upgrades. We integrate the identity provider, map groups and permissions, and harden the instance by reviewing network exposure, secrets handling, logging and access to the application database. Backups, restore tests and version tracking against Metabase's support calendar are written into the handover so your team can run them without us. Security testing of the deployed instance and the embedding layer, and the control evidence that an independent auditor would later review, can be added to the same written scope where your compliance program needs them. DeployOpen prepares systems and evidence but does not issue audit reports or certifications.
The next step is simple: send us your Sisense inventory, including ElastiCubes, data security rules, user groups and any embedded dashboards, and we will return a written scope and fixed-price quote based on it. Ask for the scope to list each assumption about data volumes, identity sources and hosting, and for the quote to separate one-time implementation and migration work from recurring support or retainer items. Until we have that inventory, treat any timeline or effort figure as unconfirmed.
