Which fits your Looker renewal: Looker or Metabase
Looker (Google Cloud core) suits teams that want a Google-hosted, LookML-governed semantic layer, and Metabase suits teams that want self-hosted, self-service BI. If your renewal is driven by a data residency rule or by the effort of maintaining LookML, the first question is where the BI instance has to run. Looker (Google Cloud core) instances are hosted by Google in Google Cloud and are not offered for customer-hosted or multicloud environments, according to Google Cloud documentation. Metabase runs as a JAR or Docker image in your own cloud account, data center or network, so the hosting decision moves to your platform team.
The second question is which controls you need on day one. Metabase's open source and Starter plans include Google sign-in and LDAP, but SSO, row and column level permissions, and usage analytics and auditing are included only in the Pro and Enterprise plans, according to Metabase's pricing page. Verified metrics also need Pro or Enterprise. Confirm the exact plan with Metabase before you commit, and map each Looker permission you rely on to a Metabase control in the same edition. If you cannot give up row-level security or SAML sign-in, budget for a paid plan in the comparison.
The third question is how much modeling your team will keep. Looker centers governance on LookML views and explores in a Git repository, which requires developers who can maintain it. Metabase models and metrics are lighter, but official definitions still need an owner, and complex joins or derived logic may belong in the warehouse or dbt. Ask which Looker explores your business depends on, then test whether each one can be rebuilt as a Metabase model with a verified metric before you decide.
Which option fits which scenario
This table maps common situations to the platform that fits them better, along with the condition that makes each choice hold. Read it against your hosting rules, your existing LookML investment and the sign-in and governance features your auditors will ask about. The main takeaway is that hosting location and modeling depth usually decide the choice before feature lists do.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Google Cloud-hosted team with deep LookML expertise | Looker (Google Cloud core) | Keeps existing LookML models, explores and Git-based development. Holds only if Google hosting is acceptable and the team wants to keep its modeling layer. |
| Must run BI on-premises, air-gapped or on another cloud | Self-hosted Metabase | Looker (Google Cloud core) is hosted by Google in Google Cloud only. Metabase runs as a JAR or Docker image in your own network. Confirm that the air-gapped option you need is on the Enterprise plan. |
| Self-service dashboards without a modeling layer | Self-hosted Metabase | Models and metrics cover curated questions without LookML. Holds if the warehouse already has clean tables and the team accepts fewer reusable, code-reviewed definitions. |
| Governed metrics kept in version control | Looker (Google Cloud core) | LookML projects map to Git repositories with GitHub, GitLab or Bitbucket connections. Metabase metrics are managed in the application, so review workflows need to be designed by your team. |
| SSO with SAML or OIDC required | Self-hosted Metabase on Pro or Enterprise | JWT, OIDC, SAML and SCIM require Pro or Enterprise. Open Source and Starter support Google sign-in and LDAP only. Confirm the plan before design. |
| Verified metrics and row-level permissions required | Self-hosted Metabase on Pro or Enterprise | Verified metrics and row and column permissions are paid features. Open Source is suitable only when these controls are not required by policy. |
| Budget limited to a free core with in-house operations | Self-hosted Metabase Open Source | The open source edition has unlimited users and dashboards. Your team pays for hosting, upgrades, backups and support, which recur. |
Where your data and BI instance live
Looker (Google Cloud core) and self-hosted Metabase differ first in where the BI instance runs, who operates it and who controls the sign-in path. The cards below cover those decisions in the order a regulated team usually meets them, from hosting boundaries to the compliance evidence you must assemble yourself.
Hosting boundary for Looker
Looker (Google Cloud core) instances are hosted by Google in Google Cloud and are not offered for customer-hosted or multicloud environments. If your data residency or network rules require BI to run on your own premises, in another cloud or inside a private network, Looker (Google Cloud core) is not an option under its current hosting model. Confirm the hosting terms in your Google Cloud contract before you assume a region or network placement.
Self-hosted Metabase deployment
Metabase runs as a Java JAR or as the metabase/metabase Docker image, so the instance sits wherever your platform team already runs workloads. Your team owns the host, the network path to each data source, patching, and the application database. The open source image and the enterprise image are separate artifacts, so confirm which one your deployment pipeline pulls before you plan change control.
Sign-in and identity paths
Looker uses Google Cloud identity for its hosted instance, while Metabase's open source edition supports Google sign-in and LDAP. SAML, OIDC, JWT, advanced LDAP group sync and SCIM provisioning require Metabase Pro or Enterprise. If your identity provider is not Google or LDAP, price the paid tier into the comparison before you commit to the architecture.
Audit trail ownership
Hosted Looker and self-hosted Metabase produce audit records in different places, and each one needs a retention rule that matches your policy. On Metabase, the application database holds user, query and configuration history, and usage analytics and auditing are part of the Pro and Enterprise plans. Ask Google what audit logs the Looker instance exposes and how long they are kept, then compare them with what your own logging pipeline must collect.
Application database as a control point
A self-hosted Metabase instance keeps its metadata in an application database, which must be backed up, access-controlled and encrypted under your own policy. Metabase recommends PostgreSQL for production and ships an embedded H2 database for demos only. Your backup, restore and key management controls apply to this database as well as to the warehouse it queries.
Compliance evidence and attestations
Moving BI in-house changes which controls you operate and which you must document. DeployOpen can prepare systems, configurations and control evidence for your compliance assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination. Ask your auditor which evidence they will accept for hosting, identity and audit logging before the migration starts.
How LookML views and explores map to Metabase models and metrics
In Looker, governance lives in code. Each LookML project corresponds to a Git repository, so view files, explores and measure definitions are reviewed, versioned and rolled back like any other source code. Metabase works differently. Its models curate data from one or more tables in the same database and can be built from a SQL or query builder question, and its metrics define the official way to calculate an important number as a reusable formula. Neither object is a code repository, so before you decide, export your current LookML from Git and list which measures, joins and filters your business depends on. Those become your Metabase metrics and models, and that list is the scope of the rebuild.
Metrics have a hard boundary. Each metric is tied to one data source, it is usable in any query builder question on that source, and it is not usable in SQL questions. If your analysts write much SQL, or if a dashboard combines tables from two databases, a metric will not cover that logic. Plan to move complex joins, deduplication and business rules that span sources into the warehouse as views or into dbt models, then point Metabase at those objects. Confirm with your Metabase team which of your current Explores depend on SQL, cross-database joins or LookML-only functions before you commit to a timeline.
Two governance controls need a paid plan. Verified metrics, which mark a metric as the trusted calculation, and checking models for breaking changes are limited to Pro and Enterprise plans on Metabase's pricing page. On the free Open Source edition, your review process for metric changes must happen in your own change control, such as a pull request to the dbt repository that holds the warehouse logic. Ask your Metabase reseller or the vendor to confirm current plan contents before you budget for those controls, since plan features can change.
Metabase editions against Looker editions
The free Open Source edition is self-hosted and includes unlimited users and dashboards, so its recurring cost is the infrastructure and staff time that run it. Starter is the first paid plan. It adds support and a per-user fee, but it leaves out several controls that regulated teams often expect. Both plans support Google sign-in and LDAP.
- License cost: Open Source has no license fee. Starter is listed at $100 per month, or $90 per month billed yearly, with the first 5 users included and $6 per month for each additional user.
- Sign-in: Google sign-in and LDAP are available on both plans, so directory-based access works without a higher tier.
- Controls left out: SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are not included in either plan.
- Verified metrics: Marking metrics as verified and caching individual metrics require Pro or Enterprise.
Before choosing either plan, confirm that your LDAP directory meets your group requirements and whether you need row-level restrictions on data.
The Pro plan is the first Metabase tier that covers the access controls most governance reviews ask about. It is listed at $575 per month, or $517.50 per month billed yearly, with the first 10 users included and $12 per month for each additional user. Support is included at this level.
- Access controls: SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included.
- Identity standards: JWT, OIDC and SAML are available, with documented setups for Auth0, Entra ID, Google, Keycloak and Okta.
- Directory sync: Advanced LDAP group and attribute sync and SCIM provisioning require Pro or Enterprise.
- Metric governance: Marking metrics as verified and caching individual metrics are available, and checking models for breaking changes is included.
Confirm which identity provider you will connect, whether you need SCIM provisioning, and which of the listed controls your audit scope will test before committing to this plan.
The Enterprise plan is the only Metabase plan that offers air-gapped deployment, which matters when the BI server must run on a network with no outbound internet access. Pricing is by quote, starting at $20,000 per year according to Metabase's pricing page. The plan covers the controls described for Pro, and the scope of any additional features should be confirmed in the written order form.
- Deployment model: Air-gapped deployment is offered only on Enterprise, so isolated networks have no lower-cost Metabase option.
- Pricing basis: The annual price starts at $20,000 and depends on the quote, including user count and support terms.
- Shared controls: SSO, row and column level permissions, multi-tenant segregation and verified metrics are available here as they are on Pro.
- Support and updates: Ask the vendor which support response terms and upgrade assistance are included in the quote.
Ask for a written quote that states the user count, deployment model, support terms and the exact features included, then compare it with the internal cost of running a self-hosted Open Source instance with the controls you need added around it.
Looker (Google Cloud core) comes in Standard, Enterprise and Embed editions. Google documents that these instances are hosted by Google in Google Cloud and are available only there, so the hosting model differs from self-hosted Metabase. Looker uses a LookML model stored in a Git repository, which is a different modeling approach from Metabase models and metrics.
- Hosting: Instances run in Google Cloud, so the platform itself is not deployed in your data center or on another cloud.
- Editions: Standard, Enterprise and Embed are the published edition names. Confirm which sign-in, embedding and administration features each one includes.
- Sign-in: Looker (Google Cloud core) uses IAM sign-in, which ties access to your Google Cloud identities.
- Model source: LookML projects map to Git repositories, which you can connect to GitHub, GitLab or Bitbucket.
Because Looker edition features and prices are set by Google Cloud, ask Google for the current edition matrix and a written price for your user and embedding needs before comparing it line by line with the Metabase plans above.
What each option costs to run
Looker and Metabase price their software in very different ways, but the total cost of either option includes hosting, data, upgrades and people. The cards below separate the license line from the running costs so you can build a like-for-like comparison before a renewal.
Looker subscription and user licenses
Looker (Google Cloud core) is a Google-hosted service, so the license is a recurring fee covering the instance, its edition and the user seats you need. Edition choice and user counts drive this line most. Ask Google Cloud or your reseller for the current edition pricing in writing, confirm which users need Developer versus Viewer access, and confirm whether Google Cloud billing terms, support tiers or committed use change the total.
Metabase Open Source is free software
The Open Source edition is free to download and run, with unlimited users and dashboards. Its cost is therefore the infrastructure and the people who run it, not a license fee. Features such as SSO and row and column level permissions are not in this edition, so a governance requirement can move you to a paid plan. Check which controls your auditors expect before you count the free edition as the full solution.
Paid Starter and Pro plans
Starter costs $100 per month, or $90 per month billed yearly, with the first 5 users included. Pro costs $575 per month, or $517.50 per month billed yearly, with the first 10 users included. Additional users cost $6 per month on Starter and $12 per month on Pro. Pro is the lowest plan that includes SSO and row and column level permissions, so the choice between plans is a governance decision as much as a seat count.
Metabase Enterprise quote
Enterprise is priced by quote, starting at $20,000 per year, and is the only plan that offers air-gapped deployment. Ask for a written quote that lists included users, support terms, deployment model and renewal conditions. Compare it with the Looker contract for the same user mix and environment. Enterprise is the right comparison only when you need the features that Pro does not include.
Infrastructure and application database
Self-hosting Metabase means you pay for compute, storage, backups and networking for the application, plus a PostgreSQL or MySQL application database for production. The embedded H2 database is for demos only. Cost rises with concurrency, high availability and backup retention. Confirm your cloud or data center costs, and whether the database is managed or self-run, before you set a budget.
Upgrades, support and people
Metabase upgrades run database migrations automatically, but they still need a backup, a maintenance window and staff time to test each release. Upgrading from older versions requires stepping release by release. Staff time, whether internal or from an implementation partner such as DeployOpen on a fixed-scope or retainer basis, is usually the largest recurring cost. Looker support is included in the Google Cloud contract, so compare it against paid Metabase support and in-house effort.
Migration and LookML rebuild effort
Moving from Looker is a one-time cost. It covers exporting LookML from Git, rebuilding explores as Metabase models and metrics, recreating dashboards and permissions, and validating numbers against Looker output. Effort rises with the number of explores, custom LookML logic and dashboards. Ask for a fixed-scope estimate that lists which LookML logic moves into the warehouse or dbt, because that work does not disappear when the BI tool changes.
What a move from Looker to Metabase involves
The sequence moves LookML logic, dashboards and access rules into a self-hosted Metabase instance in an order that keeps Looker available as the reference until each part is checked. The output is a validated Metabase deployment and a signed-off cut-over plan.
Export and review the LookML project from Git
Your team clones the LookML project from its Git repository, which Looker connects to over HTTPS or SSH, and keeps the full history with it. Engineers and the BI owner read the views, explores and model files to see which measures, joins and filters carry business logic. The step is done when the repository is archived outside Looker and every model file is listed in an inventory.
Inventory explores, dashboards and permissions
Build a list of every explore, Look, dashboard and scheduled delivery in use, with its owner and its audience. Record which Looker roles and access filters apply to each group, since row-level rules must be rebuilt in Metabase. Confirm with your own licence and admin records which features your current Looker edition provides. The step is done when each asset is tagged as keep, rebuild, retire or move to the warehouse.
Choose and size the application database
Metabase ships with an embedded H2 database for demos, and the vendor recommends PostgreSQL for production, with MySQL 8.4.0 or MariaDB 10.6.0 and later also supported with utf8mb4. Your platform team selects the engine, provisions it inside your network, and sets up backups before any data is loaded. Confirm sizing and high availability requirements with your infrastructure team, since the vendor documentation does not set them for your workload. The step is done when the database is reachable, backed up and documented.
Install Metabase and load the application database
Install the Metabase version you intend to run in production and point it at the new database. If you are moving an existing H2 file, run the documented load-from-h2 command with the same Metabase version that last updated that file, because a mismatched version will not load it correctly. The step is done when Metabase starts cleanly against the new database and the load reports no errors.
Rebuild models, metrics and permissions
Recreate the core definitions as Metabase models, which curate tables from one database or a SQL or query builder question, and define the official calculations as metrics tied to a single data source. Mark verified metrics and set row and column permissions only if your plan includes them, since SSO, row and column level permissions and verified metrics need Pro or Enterprise. Set up sign-in to match your identity provider, using Google sign-in or LDAP on the open source edition. The step is done when each high-value explore has a matching model and a reviewer has compared its results with Looker output.
Validate dashboards and run both tools side by side
Rebuild the priority dashboards in Metabase and run them alongside Looker for a period agreed by the business owners, comparing figures, filters and scheduled deliveries. Document each variance and decide whether it is a model error, a warehouse issue or an accepted difference. The step is done when the business owners sign off on the agreed set of dashboards and the variance log is closed.
Plan the upgrade path and cut over
Before go-live, set a rule for upgrades: back up the application database first, reduce a cluster to a single node for major upgrades because of the migration lock, and move release by release from versions older than 40. Check the version support page for the current long-term support dates. Redirect users, retire Looker schedules and keep the LookML repository read-only for audit. The step is done when users access Metabase as the system of record and the upgrade runbook is approved.
Questions buyers ask before choosing Metabase over Looker
How much does it cost to move from Looker to self-hosted Metabase?
The software side can be free, because the Open Source edition is self-hosted with unlimited users and dashboards, but total cost depends on what you add. Cost components include infrastructure to run the Metabase JAR or Docker image and a PostgreSQL application database, warehouse query charges, the people who rebuild models, metrics and dashboards, and support. If you need SSO, row and column level permissions or verified metrics, you need the paid Pro or Enterprise plan. The Metabase pricing page lists Starter at $100 per month ($90 billed yearly) and Pro at $575 per month ($517.50 billed yearly), with Enterprise priced by quote starting at $20,000 per year. Ask Looker for the current edition and user counts, and ask any implementation partner for a quote built from a written scope.
How long does a Looker to Metabase migration take?
The timeline is driven by how much LookML logic must be rebuilt, not by Metabase itself. The main variables are the number of explores and joins, how many persistent derived tables move into the warehouse or dbt, the number of dashboards and schedules, and how many permission groups need to be mapped. Metabase models and metrics can be built on top of existing tables, but metrics only work in query builder questions and not in SQL questions, so SQL-heavy Looks need a separate plan. No supplied figure gives a duration, so ask your team or a partner to estimate from an inventory of your LookML project and dashboards before committing to a date.
Can our team migrate from Looker to Metabase without outside help?
A team with strong SQL skills and someone who owns the warehouse can often run a small migration alone, especially when the LookML is simple. Teams usually find the harder parts are the modeling decisions, which definitions belong in the warehouse or dbt, and the access rules that Looker enforces through its own permissions. Upgrades also need care: Metabase runs application database migrations automatically, so the docs recommend backing up the application database first and reducing a cluster to a single node for major upgrades. DeployOpen plans, implements, integrates, backs up, upgrades and documents self-hosted platforms in your environment under a written scope, so you can choose to hand over the whole project, parts of it or only the upgrade and support work.
Do SSO and verified metrics require a paid Metabase plan?
Yes, both need a paid plan. According to the Metabase pricing page, SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included only in Pro and Enterprise, not in Open Source or Starter. Metabase's metrics documentation also states that marking metrics as verified and caching individual metrics need Pro or Enterprise. Google sign-in and LDAP are available in the open source edition, while SAML, OIDC, JWT, SCIM provisioning and advanced LDAP group sync require Pro or Enterprise. Confirm the current plan table on the pricing page before you finalize a budget, because plan features can change.
Can Metabase run in an air-gapped network?
Air-gapped deployment is listed on the Metabase pricing page only for the Enterprise plan, while Open Source, Starter and Pro do not include it. Open Source can still run inside a closed network because it is self-hosted, but you should confirm with Metabase whether your offline install, updates and license checks meet your policy. Plan for the update path too: releases must be downloaded and staged inside the network, and the upgrade docs describe the migrations that run on startup. Ask Metabase which packaging and licensing terms apply to your environment before you rely on the open source edition in an isolated network.
What happens to our Looker LookML models and Git history?
Each LookML project maps to a Git repository, so the model definitions can be exported from version control rather than reverse engineered from the UI. Keep that repository as the record of what the business logic was. Metabase does not read LookML, so the views, explores and joins must be recreated as Metabase models, metrics and questions, or moved into the warehouse or dbt. Plan an inventory that lists each explore, its joins, derived tables and the dashboards that depend on them, then verify results against Looker side by side before the renewal date passes.
What does Metabase need to run in production?
Metabase runs as a JAR or Docker image written in Clojure and Java and needs an application database. It 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 using utf8mb4 also supported. If you start on H2, Metabase documents a one-time load-from-h2 command, which must be run with the same Metabase version that last updated the H2 file. Plan for backups, monitoring and a version upgrade schedule, because Metabase LTS releases are supported for 14 months and non-LTS releases usually reach end of life after 2 months.
What running Metabase in production demands
Running Metabase in production starts with the application database, the store where Metabase keeps its own users, questions, dashboards, permissions and settings. Metabase ships with an embedded H2 database that suits demos only, and its documentation recommends PostgreSQL for production, with MySQL 8.4.0 or MariaDB 10.6.0 and later (utf8mb4) also supported. If your team has been evaluating on H2, plan the move early using the one-time load-from-h2 command, and run it with the same Metabase version that last wrote the H2 file. Confirm which database engine your platform team will operate, who owns its backups and where it sits relative to the Metabase nodes.
Every upgrade runs application database migrations automatically, so back up the application database before you change the version, and rehearse restoring that backup on a copy. For major upgrades, the upgrading guide advises reducing a cluster to a single node because of a migration lock, which means a short planned window in which Metabase is unavailable to some users. If your current version is older than 40, the docs call for upgrading release by release rather than jumping straight to the newest build. Check your installed version before you schedule anything, and ask whether your procurement or change board needs a written rollback plan for each step.
Support windows set the upgrade cadence. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months, and every release receives bug and security fixes until its end-of-life date. The version support page lists Metabase 64 as an LTS release published on 16 September 2026 with end of life on 1 December 2027, and Metabase 65 as released on 12 October 2026. Those dates are the researched figures for this page, but release plans change, so confirm the current LTS schedule with Metabase before you commit to a version, and build your upgrade calendar around the end-of-life date rather than the release date.
