Domo vs Metabase: when each one fits a team switching BI
Domo fits a team that wants connectors, storage, ETL and apps delivered as one managed cloud service, with the vendor operating the pipelines, data storage and sharing layer. Metabase fits a team that already has a warehouse and wants self-hosted dashboards and questions that its own staff run on its own servers. The reader facing a Domo renewal, a credit bill that rises with data movement, or a residency requirement is usually asking whether the second model can replace the first without rebuilding everything.
The first question is where data must live. Domo stores datasets and moves them through its own platform, so a residency rule may require checking which Domo regions and storage options apply to your contract. Metabase queries the database you point it at, so the data stays where your warehouse already sits, but Metabase itself stores only its application data (users, questions, dashboards and settings) in the database you configure. Ask Domo in writing where each dataset is stored and processed, and compare that with the location of your warehouse before you plan a cutover.
The second question is whether you already have pipeline tooling. Metabase does not extract, transform and load data for you, so a team that relied on Domo's Magic ETL needs a pipeline tool and a warehouse in place first. The third is who will operate the stack. Metabase's free Open Source edition includes unlimited users and dashboards, but SSO, row and column level permissions and usage analytics and auditing sit in the paid Pro and Enterprise plans, so confirm which of those controls you need before you compare totals. If your team cannot run upgrades, backups and the application database, budget for that work or buy support.
Which option fits which situation
This table maps common situations to the better fit between Domo and self-hosted Metabase, with the reason tied to bundling, credits, self-service and operating effort. Read each row against your own warehouse, pipeline tooling and residency rules, because the answer shifts when those change.
| Situation | Better fit | Reason |
|---|---|---|
| Business teams need dashboards on a warehouse you already run | Metabase | Metabase queries your existing warehouse directly, so you avoid paying for a second copy of the data inside a bundled platform |
| No pipeline tool exists and you need ingestion, transformation and storage | Domo | Domo bundles connectors, storage and ETL in one cloud platform, while Metabase leaves data movement to other tools you must deploy and operate |
| Strict data residency with all data kept inside your own infrastructure | Metabase | Self-hosting keeps queries and dashboards in your environment, though you must confirm which Domo deployment options meet your residency requirement |
| Cost driven by consumption credits for ingestion and row storage | Metabase | Self-hosted cost follows your infrastructure and staff time instead of credits, but you must budget for the pipeline and hosting components Domo would otherwise include |
| Embedded analytics for external customers | Metabase | Metabase embedding is documented, and cost follows infrastructure rather than per external account credits, but the host application must enforce tenant isolation |
| Row and column permissions and SSO are required | Metabase | These controls sit in paid Pro or Enterprise plans on Metabase, so confirm the plan that covers your needs before choosing |
| Self-service exploration by non-technical staff on modeled data | Domo | Domo's bundled data preparation and app tooling reduce the number of separate systems business users must learn, though Metabase also offers self-service questions |
| Small internal team that can operate and upgrade a Java application | Metabase | Metabase runs as a JAR with documented upgrades and an application database, so ongoing operating effort stays with your staff or a support partner |
What Domo bundles that Metabase leaves to other tools
Domo delivers connectors, cloud storage, transformation (Magic ETL dataflows) and the dashboard and app layer as one hosted service, so a single vendor contract covers most of the path from source system to chart. Metabase covers only the query and presentation layer. It connects to a warehouse or database you already run, and it stores its own application data (users, questions, dashboards, permissions) in a separate application database. Nothing in Metabase copies source data, schedules extracts or reshapes tables for you, so those jobs move to other tools.
That split changes who makes decisions. With Domo, the platform team mostly chooses which connectors and dataflows to use and the vendor operates the pipeline runtime. With Metabase, your team must select and run a warehouse (for example PostgreSQL or a columnar analytics store), a pipeline or transformation tool, a scheduler for refreshes, and the Metabase host itself. Each of these needs an owner, backups, upgrades and access reviews. Ask who will own data freshness failures at 2 a.m. before you commit to the architecture, because a broken load now shows up as stale Metabase dashboards with no vendor ticket attached.
Confirm early which Domo features your reports depend on: connector coverage for each source, dataflow logic, and any app or card-level sharing rules that rely on Domo's own storage. Then map each one to a named open-source or existing component, and check the Metabase plan you need for the access controls you rely on, since row and column level permissions and SSO sit in paid plans. Metabase pricing lists which features apply to each plan. Keep this inventory, because it becomes the scope for the pipeline and warehouse work.
Where data lives and who controls the platform
Domo runs as a vendor-hosted cloud platform, while Metabase runs wherever you deploy it, so data location, hosting duties and identity controls are the first decisions to settle. DeployOpen prepares systems, controls and evidence for compliance readiness, but independent auditors and certification bodies issue any audit report or certification.
Data location and platform control
Domo stores datasets and runs its platform in its own cloud, so the hosting location and operator are set by the vendor and your contract. With Metabase, the application server, its application database and the query path to your warehouse all sit where you deploy them. Map each data class to a location before migration, including the Metabase application database that holds dashboards, questions and user records. Ask Domo to confirm in writing where its copies of your data reside and how they are deleted at exit.
Self-hosting with the Docker image or JAR
The open-source edition can run from the metabase/metabase Docker image or from the JAR, so your platform team controls the container host, patch windows and network placement. For production, point the application database at PostgreSQL instead of the embedded H2 database that ships for demos. Plan who owns database backups, the reverse proxy, TLS certificates and upgrades, because none of these come with the software. Ask Domo which of its operational duties would move to your staff.
Air-gapped deployment needs Enterprise
Metabase's pricing page places air-gapped deployment only in the Enterprise plan, which is priced by quote starting at $20,000 per year. If your requirement is a network with no outbound internet access, treat it as a licensing question before an architecture question, and put it in the quote. Separately, confirm whether your own network controls already meet the requirement on the open-source edition, and ask Domo for its isolation terms in writing.
Identity, SSO and SCIM by plan
Open Source and Starter support Google sign-in and LDAP, while SAML, OIDC, JWT, advanced LDAP group sync and SCIM provisioning require Pro or Enterprise. Row and column level permissions also sit in those paid plans, so a single sign-on requirement can change the license tier before it changes the architecture. Decide early who deprovisions a leaver and how directory groups map to Metabase groups. Check both against your directory and against the Domo permissions you must match.
Self-service features and the conditions where they matter
Domo users often rely on governed self-service in one platform, so the question is which self-service controls Metabase provides on each plan. The four cards below cover the decisions where plan choice changes the outcome: business-user analysis, row and column access, auditing, and external users.
Questions and dashboards for business users
Metabase's free Open Source edition includes unlimited users and dashboards, so business teams can build questions and dashboards without a seat fee at that tier. This matters most when most of your Domo cards are read-only views that analysts maintain for managers. Check that your data team can model the underlying tables cleanly, since business users will only be as self-sufficient as the datasets you expose to them.
Row and column permissions
Row and column level permissions require the Pro or Enterprise plan. If Domo's row-level rules restrict regional managers to their own data, you need that control in Metabase before migrating those dashboards. Open Source and Starter do not include it, so a deployment that hides sensitive columns from some viewers must budget for Pro or design separate datasets per audience.
Usage analytics and auditing
Usage analytics and auditing are included only in the Pro and Enterprise plans, not in Open Source or Starter. Regulated teams often need to show who viewed which report and when, which Domo's governance features provide. If audit evidence is a requirement, confirm with Metabase which log data is available on your chosen plan and how long it is retained in your own database.
Single sign-on and group sync
SSO, JWT, OIDC, SAML and SCIM provisioning need Pro or Enterprise, while Open Source and Starter support Google sign-in and LDAP. Identity-led access control usually decides whether a Metabase rollout can drop Domo's user administration without a manual step. Confirm which identity provider you use and whether its group attributes must flow into Metabase permissions.
Embedding for external users
Metabase embedding serves dashboards to customers or partners inside your application, where cost follows your infrastructure rather than per-user credits. The host application must enforce tenant isolation, because Metabase's permissions do not replace your access checks. Plan this with the multi-tenant and embedding requirements in mind, and confirm which plan covers your embedding model before committing.
Metabase editions and what each one costs to license
The Open Source edition carries no license fee and is self-hosted in your own infrastructure. Metabase's pricing page describes it with unlimited users and dashboards, so the cost you carry is the infrastructure, the database that holds Metabase's application data, and the people who operate it. Metabase's license split matters here: the open-source code outside the enterprise directory is licensed under the AGPL, and the open-source Docker image (metabase/metabase) is separate from the enterprise image (metabase-enterprise). Deploy the open-source image if you run the free edition.
- No license fee: The free edition is priced at zero by Metabase, with unlimited users and dashboards.
- Image choice: Use the metabase/metabase image for this edition, not the enterprise image.
- Recurring costs: Servers, PostgreSQL or MySQL for the application database, backups and staff time still recur.
- Feature limits: SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are not included.
- Support: Vendor support is not part of this plan, so budget for internal or partner support.
Confirm with Metabase which features in your requirements sit in this plan before you commit to it.
The Starter plan is a paid tier priced per month, or per month billed yearly, and includes a fixed number of users with an additional per-user charge beyond that. According to the Metabase pricing page, Starter is $100 per month, or $90 per month billed yearly, with the first 5 users included, and each additional user costs $6 per month. It adds support and Google sign-in and LDAP, but the features that many enterprises expect, such as SSO through SAML or OIDC and row and column level permissions, sit in higher plans.
- Monthly price: $100 per month, or $90 per month billed yearly.
- Included users: The first 5 users are included.
- Additional users: $6 per month for each user beyond the included count.
- Authentication: Google sign-in and LDAP are supported, while JWT, OIDC, SAML and SCIM require Pro or Enterprise.
- Image: Starter runs on the enterprise image, so confirm the license key and image requirements in Metabase's documentation before deployment.
Calculate the yearly total for your expected user count and ask Metabase to confirm how billing and user counting work for your organization.
The Pro plan is the lowest tier that includes SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing, according to the Metabase pricing page. Its monthly price is $575, or $517.50 per month billed yearly, and it includes the first 10 users. Each additional user costs $12 per month. Teams that need SAML, OIDC, JWT or SCIM provisioning usually land here, so the Pro price is often the reference point when comparing against a commercial BI subscription.
- Monthly price: $575 per month, or $517.50 per month billed yearly.
- Included users: The first 10 users are included.
- Additional users: $12 per month for each user beyond the included count.
- Identity features: JWT, OIDC, SAML with documented setups for Auth0, Entra ID, Google, Keycloak and Okta, advanced LDAP group sync and SCIM provisioning are included.
- Governance: Row and column level permissions, multi-tenant segregation and usage auditing are available.
Confirm which identity providers and permission models you need, then match them to the Pro feature list before you compare the monthly figure with your current contract.
The Enterprise plan is priced by quote, starting at $20,000 per year according to the Metabase pricing page. It is the only plan that offers air-gapped deployment, which matters for networks with no outbound internet access. Because the price is a starting point, the final figure depends on the scope you negotiate, and the features that drive it need to be listed in writing before you sign.
- Starting price: $20,000 per year, with the final price set by quote.
- Air-gapped deployment: Only the Enterprise plan offers it, per the pricing page.
- Image: The enterprise image is used for paid plans, which is separate from the open-source image.
- Quote drivers: Expect the number of users, support level and deployment scope to affect the final figure.
- Recurring cost: The license is an annual commitment, so budget it alongside infrastructure and operations.
Ask Metabase for a written quote that names the plan, user count, support terms, deployment model and renewal terms, and compare it with the total cost of your own infrastructure and staff time.
How cost splits between Domo credits and your own infrastructure
Domo bills consumption credits for ingestion, dataflows, storage and external users, while Metabase's cost sits in a license tier (if you buy one), infrastructure and people. The cards below separate what is one-time from what recurs, and what moves each line up or down, so you can ask for a like-for-like quote.
Domo consumption credits
Domo prices usage in credits, so the bill tracks how much data you ingest, transform, store and share rather than how many seats you hold. Ask Domo to map your current credit consumption to each activity: connector syncs, dataflow runs, stored rows and external user accounts. Credits recur every billing period and tend to rise with data volume, refresh frequency and the number of external viewers.
Metabase license tier
The Open Source edition is free to self-host with unlimited users and dashboards. Starter and Pro add support, SSO, and row and column level permissions, and only Enterprise offers air-gapped deployment, priced by quote. Choose a tier based on which features you need, because SSO and row-level permissions are the main reasons a team moves up. Subscription fees recur annually or monthly.
Warehouse and compute
Metabase queries your database or warehouse directly, so the query cost moves to the platform that already holds the data. Compute on a cloud warehouse is usually billed per query or per hour of capacity, and dashboards that refresh often or scan large tables multiply it. This cost recurs, and it is the line most likely to replace Domo's storage charges, so model it from your actual query history.
Pipeline tool and hosting
Domo's connectors, Magic ETL and storage are bundled, but Metabase does not ingest or transform data on its own. You will need an ELT or pipeline tool for ingestion and a server, container platform or cloud account to run Metabase and its application database. Both are mostly recurring, and the pipeline tool cost depends on connector count and sync frequency.
Backups, upgrades and monitoring
Back up the Metabase application database before every upgrade, since the docs recommend it and upgrades run migrations automatically. Plan for a standby environment to test releases, and for backup storage that holds dashboard and permission metadata. These costs recur in storage and staff hours, and they rise with the number of environments and the frequency of your upgrade cycle.
Migration and staff time
Migration is largely one-time work: moving datasets into a queryable warehouse, rebuilding cards as questions and dashboards, and mapping row rules to Metabase permissions. Staff time is the largest variable, and it depends on how many dashboards you rebuild, how many row-level rules you have, and whether your team already runs pipelines and databases. Ask any partner for a written scope that separates one-time migration from ongoing support, so you can compare it with your current Domo renewal.
What a move from Domo to Metabase involves
The sequence moves dashboards and data from Domo into a warehouse Metabase can query, then into a self-hosted Metabase with its own application database and permissions. Each step closes with a check the team can confirm before the next one starts.
Inventory dashboards, datasets and pipelines
The BI owner lists every Domo card, page, dataset and dataflow, marks which ones business teams use, and records the source systems behind each one. Domo's own content export and the admin console show what exists, but the team should confirm what each export includes, since dataset contents and row rules may need separate handling. Done when every dashboard has an owner, a source, and a keep, rebuild or retire decision.
Choose and load the analytical warehouse
Because Metabase queries databases rather than storing data itself, the data engineering team selects a warehouse such as PostgreSQL or another SQL store that fits the volume and latency needs of the dashboards. They then move the datasets that Domo currently stores into that warehouse and validate row counts and key totals against Domo for each one. Done when each retained dataset reconciles with its Domo source for an agreed set of reports.
Rebuild the Domo pipelines in a pipeline tool
Magic ETL dataflows do not transfer as-is, so the data team recreates each transformation in a pipeline tool of their choice, scheduled against the warehouse. Credential handling and failure alerts move into the team's own secrets and monitoring setup. Done when every scheduled load runs on its new schedule and its output matches the previous Domo output for a review period the team sets.
Deploy Metabase with PostgreSQL as the application database
The platform team deploys the open-source Metabase, using the JAR or Docker image, and configures PostgreSQL as the application database rather than the embedded H2 file, which Metabase ships for demos only. The team confirms the database connection, backups and access controls for the Metabase host before any business user logs in. Done when Metabase connects to the warehouse and to the application database, and a test login succeeds.
Rebuild cards as questions and dashboards
Analysts recreate each retained Domo card as a Metabase question, combine questions into dashboards, and rewrite Beast Mode-style calculations as SQL or model logic in the warehouse. Each rebuilt dashboard is compared with its Domo original on the same filters and date range, and the owner signs off. Done when every in-scope dashboard has a documented sign-off and any differences are recorded.
Map row rules to permissions by plan
Domo's row-level rules must be translated into Metabase permissions. The team confirms which row and column restrictions they need, then checks which Metabase plan provides them, since the pricing page places row and column level permissions and SSO in Pro and Enterprise rather than Open Source. Groups are set up and tested with a sample of users from each group. Done when a test user in each group sees only the rows the rule allows.
Back up, upgrade safely and cut over
Before any Metabase upgrade, the operations team backs up the application database, because upgrades run application database migrations automatically. For major upgrades, the cluster is reduced to a single node, and older versions are upgraded release by release. Users are moved to Metabase in a planned cutover, with Domo kept read-only until the business confirms the dashboards they need. Done when the backup restore has been tested, users have access, and the Domo subscription end date is agreed.
Questions buyers ask before switching from Domo to Metabase
What does it cost to move from Domo to self-hosted Metabase?
The total depends on components you pay for separately, not on a single license line. Metabase's free Open Source edition has no license fee, but you still pay for the servers or cloud accounts that run the Metabase JAR, the PostgreSQL or MySQL application database, the warehouse Metabase queries, and any pipeline tool that replaces Domo's connectors and Magic ETL. Staff time for setup, migration, upgrades and support is usually the largest recurring item. If you need SSO, row and column level permissions, or usage analytics, the Pro plan is required, and Metabase's pricing page lists Starter at $100 per month ($90 billed yearly, with the first 5 users included) and Pro at $575 per month ($517.50 billed yearly, with the first 10 users included). Ask any quote to itemize infrastructure, pipeline tooling, migration and recurring support separately.
How long does a Domo to Metabase migration take?
The timeline is set by how much you are moving, not by Metabase itself. The main drivers are the number of datasets that must move into a warehouse Metabase can query, how many cards and dashboards must be rebuilt as questions and dashboards, how complex the Domo row-level rules are to map to Metabase permissions by plan, and how many users need to cut over together. Each of these should appear in a written scope before work starts. No migration duration is supplied for this comparison, so ask any implementation partner to base the timeline on an inventory of your Domo content, not on a generic estimate.
What does our internal team need to provide for the migration?
Your team needs to supply access and knowledge that only you hold. Typically this includes an export or inventory of Domo datasets, cards, dashboards and dataflows, the source systems and their credentials, a target warehouse or database that Metabase can query, and the list of business owners who approve the rebuilt dashboards. Security and identity staff must also decide how Metabase will authenticate users, since SSO and SAML setups require a Pro or Enterprise plan. Finally, plan for a named owner who can accept cutover and sign off on data accuracy. Confirm each responsibility in the written scope so gaps show up before cutover.
Can our own team migrate from Domo to Metabase without outside help?
A team with data engineering and BI experience can migrate on its own, and Metabase's documentation covers installation, the application database and upgrades. The harder parts are usually rebuilding Domo dataflows in a pipeline tool, preserving row-level access rules, and testing that numbers match the source. If your team lacks capacity in these areas, DeployOpen can plan, implement, customize, integrate, back up, document and support a self-hosted Metabase inside your own infrastructure under a fixed-scope agreement. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How do Metabase upgrades and version support work?
Metabase publishes two release types with different support windows. LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months. Every release receives bug fixes and security updates until its end-of-life date, as listed on the Metabase version support page. Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027, and Metabase 65 was released on 12 October 2026. Upgrades run application database migrations automatically, so back up the application database first, reduce a cluster to a single node for major upgrades because of a migration lock, and upgrade release by release if you are coming from a version older than 40.
Can Metabase run in an air-gapped network?
Air-gapped deployment is available only on Metabase's Enterprise plan, according to Metabase's pricing page. The free Open Source edition is self-hosted with unlimited users and dashboards, but it does not include air-gapped deployment as a listed feature. Enterprise is priced by quote starting at $20,000 per year. Before you plan around this, confirm with Metabase which components, such as license validation and updates, must reach the network, and confirm how your own air-gap policy treats the Metabase JAR and container images that are pulled into the isolated environment.
What should we check about the application database before going live?
The application database stores Metabase's users, questions, dashboards and settings, so its setup affects reliability and recovery. Metabase ships with an embedded H2 database for demos and recommends PostgreSQL for production, with MySQL 8.4.0 or MariaDB 10.6.0 and later also supported when using utf8mb4. If you start on H2 for a pilot, Metabase documents a one-time load-from-h2 command to move to PostgreSQL or MySQL, which must run with the same Metabase version that last updated the H2 file. Confirm your backup and restore process for this database before cutover, because upgrades depend on it.
Who operates each stack day to day
Domo's day-to-day operation sits with Domo: the platform, connectors, storage and hosted runtime are run by the vendor, so your team manages content, users and data logic inside the product. A self-hosted Metabase stack moves those jobs to your staff. Someone must own the host or cluster, the application database, identity integration with your SSO provider, backups, monitoring, and the warehouse and pipeline tools that feed Metabase, because Metabase queries data but does not move or store it for you. Before you commit, name an owner for each of these in writing and confirm whether that person sits in platform engineering, data engineering or a partner's managed service.
Upgrades are the recurring task most teams underestimate. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after about 2 months, so a non-LTS install needs an upgrade roughly every two months to stay supported. Plan a release calendar, a staging copy of the application database, and a rollback path. Metabase runs application database migrations automatically at startup, and its upgrading guide recommends backing up the application database first, reducing a cluster to a single node for major upgrades because of a migration lock, and upgrading one release at a time from versions older than 40. Confirm the current end-of-life dates on the Metabase version support page before setting your cadence.
Identity is the other ongoing dependency. Open Source and Starter plans support Google sign-in and LDAP, while JWT, OIDC, SAML and SCIM provisioning require Pro or Enterprise, so the plan you choose decides who maintains the directory link. Ask your identity team which protocol you will use and whether group sync is required before you size the operating model. Finally, budget staff time for the upstream data path, since a Domo customer who gave up connectors and dataflows must now maintain them as code or tooling of their own.
How DeployOpen helps evaluate and move from Domo to Metabase
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Metabase. For Domo vs Metabase, the work starts with an inventory of what Domo does for your teams today, then a written scope that separates dashboard delivery from the connectors, storage and ETL you would need to replace.
How we scope
- Inventory Domo cards, pages, dataflows and external users to see which dashboards business teams actually depend on
- Map each Domo capability to a Metabase feature or a separate tool such as a warehouse and pipeline
- Agree scope, deliverables and timelines in writing before work starts, with fixed-scope engagements
How we build
- Stand up Metabase on your infrastructure with PostgreSQL as the application database rather than the embedded H2 database
- Set up SSO and row or column permissions on the plan tier you choose, confirmed against current Metabase pricing
- Rebuild priority dashboards as Metabase questions and dashboards and test results against Domo figures
How we hand over
- Document the deployment, upgrade runbook, backup procedure and permission model for your administrators
- Provide a cutover checklist covering user access, scheduled reports and retirement of Domo content
- Walk your team through building new questions and dashboards so analysts can maintain them
How we support
- Ongoing support, version upgrades and continuous testing are available as retainers after handover
- Plan Metabase upgrades around the version support dates published by Metabase and back up the application database first
- Review data access and permissions periodically as teams, plans and data sources change
