Should you stay on self-managed ThoughtSpot or move to self-hosted open-source BI?
If you already run ThoughtSpot Software in your own datacenter, the decision in front of you is whether a renewal, a licensing change or a need to control upgrade timing justifies a move to self-hosted Apache Superset or Metabase. Staying is the lower-effort path while your current agreement covers your users and your release schedule suits your change process. Moving makes sense when the renewal price, the feature set you need or your upgrade control no longer fit. The constraint most owners share is simple: the data stays on infrastructure you own, and you decide when each release lands. Both open-source options can run on the same hardware, so the real trade-offs are feature fit and operating effort, not hosting location.
Before comparing, get the numbers from ThoughtSpot. No pricing for self-managed ThoughtSpot Software is available to this page, so ask your account team for a written renewal quote that names the license metric, the number of users or cores covered, the support tier and any credit or usage terms. Ask which release line the quote covers, how long each release is supported and what happens to your deployment if the subscription lapses. Those answers set the cost of staying, and they are the baseline for any open-source business case.
On the open-source side, the costs are the infrastructure, the metadata database, staff time for upgrades and backups, and any support contract you choose to buy. Superset's own upgrade guidance asks you to back up the metadata database, run its upgrade commands and test in staging first, and Metabase recommends backing up its application database before each upgrade. Plan that recurring work and the migration of your content as separate line items, and confirm with the vendor or your own team how much of your ThoughtSpot semantic model and search usage each option can reproduce before you commit.
What a self-managed BI constraint requires from the platform
If your ThoughtSpot Software deployment must stay inside your own datacenter, the replacement has to meet the same hosting, identity, upgrade and licensing conditions. The cards below list the requirements that matter most, and what to confirm with ThoughtSpot or the open-source project before you commit to a path.
Metadata stays on your servers
A self-hosted BI tool keeps dashboards, semantic definitions and the metadata database inside your network only if every component runs there. Apache Superset stores its metadata in PostgreSQL or MySQL, and Metabase keeps its application database separate from the data it queries. Confirm with ThoughtSpot where its self-managed metadata, cache and search indexes live, and confirm that no feature in your plan calls an external service. Ask the project which components, including any optional caching or worker layer, must run in your environment.
Supported metadata database versions
Your platform team must choose a metadata database that the project tests and supports. Superset documents PostgreSQL 10 to 17 and MySQL 5.7 and 8.x as supported metadata databases, and it advises against the SQLite default for production. Metabase recommends PostgreSQL for production and supports MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4. Verify that your database team already operates a supported version, and check the backup and high availability model for that database before go-live.
Identity and single sign-on coverage
Most enterprise BI rollouts depend on directory groups deciding who sees which data. Superset supports database, LDAP and OAuth authentication through Flask-AppBuilder and can map LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING. In Metabase, SSO, JWT, OIDC, SAML, advanced LDAP group sync and SCIM provisioning sit in the Pro or Enterprise plans. Confirm which identity protocol your directory uses and which group attributes must drive row-level access, then test that mapping in staging.
Controlled upgrades with backup and staging
Self-managed software only stays secure if you can apply vendor releases on your own schedule. For Superset, the upgrade path requires backing up the metadata database, running superset db upgrade and superset init, testing in staging, and checking UPDATING.md for breaking changes. Metabase runs application database migrations automatically, so you should back up first, reduce a cluster to one node for major upgrades, and move through releases in order from versions older than 40. Ask ThoughtSpot for its patch and end-of-support policy for your release line, and set a written upgrade calendar for whichever tool you choose.
Metabase version lifecycle
Support windows determine how often you must upgrade. Metabase LTS versions receive support for 14 months, while non-LTS versions usually reach end of life after about two months, and every release gets security fixes until its end-of-life date. Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027. Before you pick a version, check the current version support table and plan your upgrade cadence around the LTS line, not the newest non-LTS release.
Licensing that remains valid
The license that governs your deployment must still work at the end of your planned life. Tableau's documentation states that a term subscription stops working when it expires, which is the same risk to check in any commercial BI contract. Apache Superset is Apache-2.0 with no paid edition, so no license key is required to keep it running. Metabase's open source edition is AGPL-3.0, but features such as SSO and row-level permissions need a paid plan. Ask ThoughtSpot whether your self-managed license is perpetual or term, and confirm which features each open-source edition includes before you rely on them.
Where self-managed ThoughtSpot meets the constraint and where it leaves you carrying the work
Staying on self-managed ThoughtSpot Software means you host the platform in your own datacenter, decide when each release is applied, and run everything around it: the servers or nodes, the operating system, the database tier, network paths, backups and the identity integration your users sign in through. The vendor supplies the software and its release line, but the schedule and the change window are yours to plan. Before you commit to another renewal, get the release cadence, support windows and licensing terms of ThoughtSpot Software confirmed in writing. Ask which releases receive fixes, how long each one is supported, what happens to your license if you fall behind, and whether upgrade assistance is included or billed separately. Those answers set the cost of staying put.
The work you carry on the self-managed line falls into three groups: applying releases, keeping the surrounding stack current and showing that each change is controlled. Release application needs a staging copy that mirrors production closely enough to catch regressions in your data connections, saved content and user access rules before users see them. Surrounding stack work covers operating system and database patching, certificate renewal, capacity planning as user counts and data volumes grow and monitoring of the service itself. Each task is staff time, and most recur with every release. Confirm with the vendor which of these steps it documents, which it supports and which it leaves to your team.
Moving to Apache Superset or Metabase on the same infrastructure keeps the same categories of work but changes their size and sequence. Superset's upgrade guidance asks you to back up the metadata database, run superset db upgrade and superset init, test in staging first and check UPDATING.md for breaking changes between versions. Metabase runs application database migrations automatically during an upgrade, so its guidance centers on backing up the application database first, reducing a cluster to a single node for major upgrades and upgrading release by release from versions older than 40. Both sets of steps are documented and open for your team to inspect, so the upgrade plan becomes a document you write and test. Include the staging run in your estimate, because it is the step that proves the rest of the plan works.
How Apache Superset and Metabase compare on feature fit and licensing
Apache Superset is an Apache Software Foundation project released under the Apache License 2.0 (Apache-2.0). The project has no paid edition, so the software carries no license fee at any user count. Your costs sit in infrastructure, in the staff who run the platform and in any third-party support you choose to buy. Version 6.1.0 was released on May 13, 2026, and the GitHub releases page already lists a 7.0.0 pre-release, so confirm which release line your team will standardize on before you build.
- Metadata database: Superset stores its own metadata in PostgreSQL or MySQL. The configuration documentation lists PostgreSQL 10 to 17 and MySQL 5.7 and 8.x, and the SQLite default is not intended for production.
- Authentication: Built on Flask-AppBuilder, Superset supports database, LDAP and OAuth2 sign-in, including Google, Azure and custom OAuth2 servers that use the code flow.
AUTH_ROLES_MAPPINGmaps LDAP or OAuth groups to Superset roles. - Secret handling: A user-specified
SECRET_KEYis required to start, andPREVIOUS_SECRET_KEYsupports key rotation. - Asynchronous features: Alerts and reports, async queries and dashboard thumbnails need the caching layer and Celery worker components, and most installations use Redis and Celery.
Confirm with your security team which authentication method maps cleanly to your identity provider, and price the Redis and worker hosting that these features add.
Metabase is open core. Its Open Source edition is free to self-host with unlimited users and dashboards, and the code outside the enterprise directory is licensed under the AGPL. The paid plans add support and specific controls. The pricing page lists the following, and you should recheck it before purchase because plans change.
- Open Source: Free to self-host, with unlimited users and dashboards. Google sign-in and LDAP are included, but SSO, row and column level permissions, multi-tenant segregation and usage analytics and auditing are not.
- Starter: $100 per month, or $90 per month billed yearly, with the first 5 users included and additional users at $6 per month. It adds support but not the Pro-level access controls.
- Pro: $575 per month, or $517.50 per month billed yearly, with the first 10 users included and additional users at $12 per month. It adds JWT, OIDC and SAML single sign-on, SCIM provisioning, advanced LDAP group sync, row and column permissions, multi-tenant segregation and usage analytics and auditing.
- Enterprise: Priced by quote, starting at $20,000 per year. It is the only plan that offers air-gapped deployment.
Ask for the plan that matches your user count and your SSO and permission requirements in writing, including how the additional-user fees will be billed in your case.
Metabase ships with an embedded H2 application database for demos, and it recommends PostgreSQL for production. MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4 are also supported. If a trial instance has been running on H2, plan a one-time move. Metabase documents a load-from-h2 command for this, and it must be run with the same Metabase version that last updated the H2 file.
- Application database: Move from H2 to PostgreSQL or MySQL before users depend on the instance, and validate dashboards, questions and permissions after the move.
- Migrations: Upgrades run application database migrations automatically. Back up the application database first, and reduce a cluster to a single node for major upgrades because of a migration lock.
- Upgrade path: Upgrade release by release from versions older than 40, as the upgrading documentation directs.
- Support windows: LTS versions are supported for 14 months. Metabase 64 is an LTS release published on September 16, 2026, with end of life on December 1, 2027. Non-LTS versions usually reach end of life after about 2 months, and Metabase 65 was released on October 12, 2026.
Choose an LTS line for production, and schedule an upgrade window at least once per support period so your team is not forced into a major upgrade under deadline.
Natural-language search is the main feature gap to test for this migration. ThoughtSpot's search lets business users type a question and receive a chart. Neither Apache Superset nor Metabase should be assumed to offer the same experience out of the box, and the supplied research does not confirm search-style natural-language querying for either. Treat this as an open question for each tool, not as a settled answer.
- Superset: Users work with datasets, charts, dashboards and SQL Lab. Confirm with the vendor or the current documentation whether any natural-language or AI query feature exists in the release you plan to run, and whether it is available without a commercial add-on.
- Metabase: Users work with the query builder, models and metrics. Confirm whether any natural-language question feature exists in the edition and version you plan to run, and which plan includes it.
- Semantic layer: Whichever tool you choose, the answers depend on well-defined datasets, models and metrics. Budget time to document joins, definitions and filters before testing user questions.
- Test set: Build a list of questions that your ThoughtSpot users ask most often, then check each option against that list in your own environment.
Record the answers in writing, because a gap in natural-language search changes training, adoption and the amount of modeling work your team will need.
How to deploy the chosen option on your own infrastructure
This sequence moves ThoughtSpot content out of the self-managed installation and into a tested, self-hosted Superset or Metabase stack, with each stage closing on a check you can verify. It is the order most teams follow, adjusted to their own data sources and identity setup.
Inventory and export ThoughtSpot content
Your BI or platform team lists every Model, Worksheet or View, Answer, Liveboard, alert and user group in the ThoughtSpot instance, then exports them as TML files using the export method in your release. Keep the TML set under version control so it becomes the specification for the rebuild. Done means every in-scope object has a TML file, a named owner and a note on whether it will be rebuilt, retired or left in ThoughtSpot during the transition.
Provision the metadata database and application server
Your infrastructure team deploys PostgreSQL for the metadata store, since Superset and Metabase both recommend it for production, and provisions the application host or container platform inside your own network. For Superset, confirm the PostgreSQL version against the supported range in the configuration docs. For Metabase, confirm the application database version as well. Done means the database is reachable only from the application tier, backups are scheduled, and a health check passes.
Configure secrets and authentication
Your platform team sets a unique SECRET_KEY for Superset before first start, because the application will not run without one, and stores it in your secrets manager. Then the identity team configures authentication: database, LDAP or OAuth2 for Superset through Flask-AppBuilder with group-to-role mapping via AUTH_ROLES_MAPPING, or SSO for Metabase, where JWT, OIDC and SAML sit on the Pro or Enterprise plans. Done means test users log in through the chosen method and receive the roles you expect.
Stand up a staging environment
Deploy a second, identical instance in staging with the same versions and configuration, using a copy of the metadata database or a fresh one. Connect it to non-production copies of your warehouses so the team can test without touching production data. Done means the staging instance loads, runs a sample query against each source, and the team has documented the connection settings it used.
Run the documented migration or upgrade steps
For Superset, back up the metadata database, run superset db upgrade and superset init, and read UPDATING.md for breaking changes between versions before running them in staging. For Metabase migrating from H2, use the one-time load-from-h2 command with the same Metabase version that last wrote the H2 file, then confirm the migrated application database opens. Once Metabase is running on PostgreSQL, future upgrades run migrations automatically, so back up the application database first. Done means the staging instance starts on the target version with no migration errors.
Rebuild and validate dashboards and permissions
Recreate the highest-value Liveboards as Superset dashboards or Metabase dashboards using the TML export as the specification, then compare results against the ThoughtSpot figures for the same filters. Test row-level and column-level restrictions with a representative user from each group, since these depend on the plan you chose. Done means signed-off reviewers have compared key numbers and access tests pass for every role.
Cut over and retain a rollback path
Schedule the cutover with the business owners of each dashboard, point users and scheduled reports to the new instance, and keep the ThoughtSpot environment read-only until the agreed review. Confirm alerts and scheduled reports fire, and that the Superset caching and worker components or Metabase equivalents are running if you use them. Done means each in-scope dashboard has a named owner in production and the rollback steps are documented and tested.
Evidence auditors and regulators ask for under this constraint
Whichever path you choose, an auditor will ask you to show how the BI platform is configured, protected, backed up, upgraded and licensed. The cards below cover the records that answer those questions for either staying on ThoughtSpot Software or moving to a self-hosted open-source tool. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any audit report or certification.
Authentication and role mapping configuration
Keep versioned exports of how users sign in and what roles they receive. For Apache Superset, this means the authentication settings in superset_config.py and the AUTH_ROLES_MAPPING entries that map LDAP or OAuth groups to roles. For self-managed ThoughtSpot, capture the equivalent identity provider and group-to-privilege settings from its admin console. Check that the records show who approved each mapping, when it changed and that the SECRET_KEY is handled outside the config file itself.
Metadata database backup and restore tests
Auditors look for proof that a restore works, not only that a backup job ran. Record each backup of the metadata database, the date, the storage location and the result of a timed restore into a staging environment. Superset stores its metadata in PostgreSQL or MySQL, and Metabase recommends PostgreSQL for its application database, so the test should cover that database engine. Document who performed the test and what the restored system was checked against.
Upgrade change records tied to release notes
Each upgrade should have a change record that names the source version, the target version and the release notes or UPDATING.md entries reviewed for breaking changes. Include the staging test results and the database migration output from the upgrade. For Metabase, note whether the upgrade ran automatically and whether a cluster was reduced to one node for a major release. Recording the version lifecycle helps you show that you stayed on a supported release line.
Access permission exports
Export the list of users, groups, roles and dataset or dashboard permissions on a fixed schedule and keep the files with the date of export. Auditors use these to test least privilege and to confirm that leavers lost access. For Metabase, check whether row and column level permissions are in use, because those controls depend on the plan you buy. Compare each export against the approved role design and record any exceptions with an owner and a close date.
License documents for the chosen option
Keep the license terms that govern the software you run. For self-managed ThoughtSpot, this is your subscription or contract and its entitlement records. For Apache Superset, keep the Apache-2.0 license text and the version you deployed. For Metabase, record which edition you run, because the open-source code is AGPL-3.0 and enterprise directory code falls under the Metabase Commercial License. Confirm with each vendor or your counsel how these terms apply to your use.
Exported workbook and content inventory
Keep a dated inventory of every dashboard, model and data source in scope, along with the export files used to rebuild them. For ThoughtSpot, this is the TML export set. Auditors use the inventory to confirm that the data a report shows is traceable to an approved source and that nothing was left behind in a retired system. Store the export files under the same retention rules as the rest of your evidence, and record the decision for any object you chose not to migrate.
Questions buyers ask before choosing between ThoughtSpot and open-source BI
What drives the cost of staying on ThoughtSpot versus moving to open-source BI?
The cost of staying is driven by the ThoughtSpot Software license, the infrastructure it runs on, the staff time to operate it, and the upgrade effort it adds each year. The cost of moving is driven by one-time migration work plus the recurring hosting, database, support and upgrade work for Apache Superset or Metabase. Apache Superset has no paid edition, so its license line is zero, while Metabase's free Open Source edition covers many self-hosted needs. Ask ThoughtSpot for the license term, the user or capacity basis, what is included in support, the infrastructure they expect you to provide, and any renewal uplift. Compare those lines with your own estimate for hosting, staff time and migration.
How long does a migration from ThoughtSpot take?
The duration depends on the number of Models, Liveboards and Answers in scope, how many of them are used every week, how complex the joins and formulas are, and how many data sources they read from. Users who depend on search-style questions usually need more time for retraining and validation than the dashboards themselves. Export your content as TML first, so the inventory is known before any estimate is made. Ask any implementation partner for a timeline in a written scope that lists the objects, the data sources, the test cycles and the cutover plan, rather than accepting a generic duration.
What does the migration need from our own team?
The work needs a data owner who can confirm metric definitions, a data engineer or analyst who understands the warehouse schema and the existing joins, and an infrastructure owner for the servers, database, networking, certificates and secrets. Business users are needed for acceptance testing, because they know which numbers must match the current reports. Security and identity staff are needed to configure SSO and group mappings. Plan for a sponsor who can settle conflicting metric definitions, since those disputes usually take longer than the technical rebuild.
Can our internal team run the migration alone?
A capable internal team can run a small migration alone, especially if it already operates data platforms and has someone comfortable with SQL, Docker or Kubernetes, and Git. The harder parts are usually the semantic model rebuild, the access model, the upgrade process, and the ongoing operation of the metadata database and any caching or worker components. Ask yourself whether the team has capacity for the migration while keeping the current reporting running. Many organizations split the work: internal staff own the data and business decisions, while an implementation partner handles deployment, hardening, backup, testing and documentation under a written, fixed scope. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and offers retainers for ongoing support.
Which Metabase plan is needed for SSO and row-level permissions?
Single sign-on and row and column level permissions require the Pro or Enterprise plan. The free Open Source edition and the Starter plan do not include them, although Starter supports Google sign-in and LDAP. If you need JWT, OIDC or SAML setups, or advanced LDAP group and attribute sync and SCIM provisioning, Pro or Enterprise is also required. Confirm current inclusions on the Metabase pricing page before budgeting, because plan contents change. Enterprise pricing is by quote, starting at $20,000 per year according to that page, and Enterprise is the only plan offering air-gapped deployment.
Does Apache Superset support natural-language or search-style questions?
No, Apache Superset does not offer a ThoughtSpot-style natural-language or search-driven question interface. Users explore data through charts, dashboards and SQL Lab, and analysts build datasets and metrics that those charts use. If search-style self-service is central to your ThoughtSpot use, plan for a different user experience, training, and a curated set of datasets with clear names. Confirm the current feature set against the Apache Superset repository and test with real users before deciding, since search features may change between releases.
What operating work does a self-hosted Superset or Metabase stack add?
Operating work includes running the application and its metadata database on PostgreSQL or MySQL, backing up that database before every upgrade, and testing upgrades in staging. Apache Superset also needs a caching layer and worker processes for alerts, reports and async queries, which are commonly Redis and Celery, and a user-specified SECRET_KEY. Metabase runs its application database migrations automatically on upgrade, and it recommends PostgreSQL for production, so the database plan matters. Track the lifecycle of your chosen version: Metabase LTS releases are supported for 14 months, and non-LTS releases usually reach end of life after 2 months. Include monitoring, certificate renewal and access reviews in your operating estimate.
When staying on ThoughtSpot still makes sense
Staying on self-managed ThoughtSpot Software is the right call when the cost of change is higher than the cost of the current licence. The strongest argument for the self-managed path is continuity: existing Models, Liveboards, saved Answers, row-level security rules and the user habit of asking questions in search form all keep working without a rebuild. Business users who rely on search-style exploration do not need to relearn a new interface, and the analysts who maintain the semantic layer do not need to rewrite joins and formulas. For organizations with a data residency requirement that ThoughtSpot already meets in their own datacenter, the operating model may already be approved by security and audit teams, which has its own value. Ask ThoughtSpot for the written support lifecycle and upgrade path for the release line you run, and confirm how long your current version will receive fixes before you plan any change.
The move becomes harder when the dependencies are deep. Check how many Liveboards, Answers and Models are embedded in other applications, how much of the logic lives in formulas that only ThoughtSpot evaluates, and how many users depend on search rather than dashboards. Heavy use of embedding, custom SSO mappings and scheduled alerts raises the effort on both sides, so list each integration and its owner before you decide. Also confirm internally whether your datacenter hardware, database platform and operating system support the release you will need next, because upgrade windows and staging capacity often decide the timing more than licence terms do. Ask ThoughtSpot to confirm, in writing, what your current licence and support entitlement cover and what changes at renewal.
Decide with a documented inventory, not a feeling. Export the current content with TML so the object count, join logic and permission model are on record, then score each workflow by how much it depends on search-based questions. If most consumption is dashboard viewing and a small group builds content, a self-hosted tool may cost less to run than the effort to keep a specialist platform current, and a pilot with a subset of users can test that without committing the whole estate. If search is central and users would be retrained at scale, staying on the current line is usually the lower risk until the next renewal gives a clearer picture. Either way, record the decision, the review date and the conditions that would reopen it.
How DeployOpen plans and runs a self-hosted BI deployment
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure. For a move from self-managed ThoughtSpot Software to Apache Superset or Metabase, we start with a written scope that fixes what changes, what stays and how the work is checked before anything is cut over.
How we scope
- Inventory the ThoughtSpot release, the connected data sources and the Liveboards and users that depend on them
- Agree in writing which content moves, which is retired and which needs rebuilding by hand
- Confirm the target host, metadata database, authentication source and upgrade cadence before any build starts
How we build
- Deploy Superset or Metabase on your own servers with PostgreSQL or MySQL as the application database
- Configure SSO with your identity provider and map groups to roles, checking which features your chosen edition includes
- Test dashboards and permissions in a staging environment that mirrors production before any user access is opened
How we hand over
- Deliver configuration, runbooks for backup, restore and upgrades, and a record of the migration decisions made
- Document which ThoughtSpot objects were exported, rebuilt or dropped, so business owners can sign off each item
- Walk your operations team through routine tasks so they can run the platform after handover
How we support
- Engagements are fixed-scope, and we can add ongoing support, upgrades and continuous testing as a retainer
- Upgrades follow your staging process and the project's own upgrade notes, with a backup taken first
- Ask for the retainer terms and response arrangements in writing alongside the scope
