Metabase Open Source vs Pro vs Enterprise

The free Open Source edition of Metabase is missing the controls that most enterprise security reviews ask for first. According to the Metabase pricing page, row and column level permissions, SSO, caching controls, usage analytics and auditing, and multi-tenant data segregation are included only in Pro and Enterprise. If your policy requires that analysts see only their region's rows, that finance columns are hidden from other departments, or that every login is tied to a corporate identity with usage records, the free edition does not meet those needs on its own. Those requirements should drive the plan decision before anything else, because they are the features that force a move to Pro. On the identity side, the distinction matters in detail. Open Source and Starter support Google sign-in and LDAP, but JWT, OIDC, SAML and SCIM provisioning, along with advanced LDAP group and attribute sync, require Pro or Enterprise, according to Metabase's people and groups documentation. Before you assume the free edition covers your directory, confirm which protocol your identity provider uses, whether group membership must map to Metabase groups, and whether users must be deprovisioned automatically. Those answers determine whether LDAP alone is enough or whether you need Pro for the SAML or OIDC path. Multi-tenant segregation is the requirement teams most often underestimate, especially when Metabase is embedded in a customer-facing product. Pricing states that everyone who signs in directly or through SSO counts as a billed user, including users of embeds accessed through your product, so the count can grow with your customer base. Ask Metabase to confirm how billing and tenant isolation apply to your embedding model before you commit, and check the embedding introduction for the options each plan supports.

Every Metabase edition needs an application database, and the choice is the first operating decision. Metabase ships with an embedded H2 database for demos, and its documentation recommends PostgreSQL for production. MySQL 8.4.0 or MariaDB 10.6.0 and later are also supported, provided the database uses utf8mb4. Questions, dashboards, users and settings all live there, so it needs its own backup schedule and restore test. If your instance still runs on H2, plan the one-time load-from-h2 migration before anything else, and run it with the same Metabase version that last wrote the H2 file. Pro and Enterprise change none of this work, because the application database is the same across the paid tiers.

Release work is the recurring cost. Metabase runs application database migrations automatically on upgrade, and its upgrade guidance asks you to back up the application database first, to reduce a cluster to a single node for major upgrades because of a migration lock, and to step through each release when upgrading from a version older than 40. Check the Metabase version support page for the current LTS line and end-of-life dates before you choose a target. Metabase 64 is an LTS release with end of life on 1 December 2027, so a planned move to it sets a clear window. Confirm the maintenance window, rollback steps and who approves a major upgrade before go-live.

Decide who carries this work before you pick an edition. Internal platform or data staff can run backups, upgrades and monitoring, and the open-source edition has forum-only support, so their knowledge is the main safety net. A consultant can take the work under a fixed-scope agreement with written deliverables, such as a tested backup and restore procedure or a documented upgrade runbook. A retainer covers recurring upgrades and monitoring over time. Ask any provider to state which tasks are one-time and which recur, what evidence they hand over, and how a failed migration is rolled back. Metabase does not publish a duration for these tasks, so ask for the scope in writing rather than a time estimate.

Choose Enterprise over Pro only when a requirement outside the software forces it. Metabase states that Pro and Enterprise are feature-wise the same software, so the premium buys support, procurement help, deployment options and account management rather than extra BI capability. Enterprise starts at 20,000 US dollars per year, and the published Enterprise tier adds custom pricing, procurement help, a dedicated success engineer, a 1-day support SLA and the option of air-gapped deployment. If your procurement policy requires a named vendor support path, a contractual response window or a dedicated contact, those items are the reason to pay. If none of them appear in your requirements, the same row-level permissions, SSO and auditing are available on Pro at 575 US dollars per month, or 6,210 dollars a year billed yearly, for the first 10 users.

Air-gapped deployment deserves separate scrutiny because the Pro price does not include it. The Metabase pricing FAQ says air-gapped deployment is available on Enterprise only and carries an additional fee. Before you request a quote, confirm with the Metabase sales team whether your network model needs that option, what the fee covers, and whether your Pro licence can be converted without rebuilding the instance. Also confirm how the 1-day support SLA is measured, what severity levels it applies to, and whether the success engineer is included in the base Enterprise fee. Ask for these terms in writing, because the published pricing page is a starting point and current terms can change.

Pro is the right choice for teams that need the paid features, such as SSO through SAML or OIDC, row and column permissions and usage auditing, but can run their own incident response and rely on Metabase's standard channels. Plan the annual cost against your user count, since everyone who signs in directly or through SSO is billed, including embedded end users. Confirm current Enterprise and Pro terms directly with Metabase before you budget, and capture the agreed support path, SLA definitions and any air-gap fee in your procurement record.