Open-source alternatives to Looker

Which open-source alternative to Looker fits your team

Lightdash fits teams that want a modeling layer close to LookML and tied to dbt. Apache Superset fits broad self-service alongside engineering-led dashboards, and Metabase fits teams whose main need is simple self-service exploration. Most readers arriving here face a renewal, a data residency requirement or lock-in to a platform that only runs in Google's cloud. The choice depends less on chart features than on where your metric definitions will live after the move and who will maintain them.

The core constraint is hosting. Looker (Google Cloud core) is hosted by Google in Google Cloud and is not available for customer-hosted or multicloud environments, so teams that must keep analytics in their own data centers, an air-gapped network or a non-Google cloud need a different platform. A second fact eases the move: each LookML project corresponds to a Git repository, and Looker connects to GitHub, GitLab or Bitbucket over HTTPS or SSH. Export those repositories first. Then confirm what the repository does not hold, such as user roles, scheduled deliveries and permissions set in the Looker admin console, because those must be rebuilt separately.

Before you choose, run three checks. First, decide where metric logic will live. Lightdash keeps modeling close to dbt, while Superset datasets and Metabase questions carry more logic inside the tool, so count how many explores and calculated fields you would need to rebuild. Second, confirm the licensing boundary. Lightdash and Metabase both split open-source code from enterprise code, and Metabase's row and column level permissions and air-gapped deployment are paid features, so check the current plans and get the edition in writing. Third, test Superset against your warehouse using its Python DB-API driver and SQLAlchemy dialect before committing.

Lightdash, Apache Superset and Metabase compared for Looker replacement

Each option below can take over some part of what Looker does, but they divide the work differently. Lightdash keeps a dbt-centred semantic layer closest to the LookML model, Apache Superset gives the widest database reach through SQL datasets, and Metabase gives the simplest self-service path. Compare them on where your metric definitions will live, which licence terms apply to your deployment, and which features you need before you sign up for a pilot.

Lightdash on a dbt semantic layer

Lightdash reads metric and dimension definitions from dbt projects, so the business logic that currently sits in LookML views can move into dbt models and YAML. This suits teams that already run dbt and want metrics versioned next to their transformations. The trade-off is licensing: content outside the packages/backend/src/ee directory is MIT licensed, while the ee directory uses a separate license. Before you build on it, have counsel confirm which Lightdash features you need fall under the ee terms and whether your intended deployment is covered.

Apache Superset for broad SQL access

Apache Superset connects to any SQL datastore with a Python DB-API driver and SQLAlchemy dialect, which makes it the strongest option when your warehouse mix is varied. Its metadata lives in PostgreSQL or MySQL, and authentication can run through database, LDAP or OAuth via Flask AppBuilder. Superset has no LookML equivalent, so you rebuild the model as datasets, virtual SQL and metrics, and you own the governance of those definitions. Confirm that your identity provider and driver versions work together during the pilot, since Superset's logic depends on them.

Metabase for self-service exploration

Metabase is open core: code outside the enterprise directory is AGPL-3.0, and code inside it is under the Metabase Commercial License. The free Open Source edition is self-hosted and has no user or dashboard limits, which makes it a low-friction entry point for business users. The main trade-off is that air-gapped deployment appears only on the Enterprise plan, and row and column level permissions require a paid plan. If you operate in an isolated network, confirm the edition and plan that support it before you design the architecture around it.

How each Looker capability maps to open-source options

This table maps each major Looker capability to the open-source platform that fits it best, with notes on coverage and gaps. Treat the notes as a starting checklist: confirm each feature against the current release of the platform you plan to run before you commit to a design.

Capability	Best-fit open-source option	Coverage notes and gaps to confirm
LookML modeling	Lightdash (dbt-based) or Apache Superset datasets	Lightdash builds on dbt models and metrics, so LookML logic moves to dbt YAML rather than a one-to-one copy. Superset datasets cover SQL-defined virtual datasets but have no LookML equivalent, so expect to rewrite joins and measures.
Explores	Metabase questions or Superset explore view	Both let business users pick tables and fields without SQL. Confirm how each handles joins across your largest tables and whether field-level descriptions carry over from your LookML.
Dashboards and looks	Apache Superset dashboards, Metabase dashboards, Lightdash dashboards	All three offer dashboards with filters. Saved single-chart content (looks) maps to saved questions or charts. Export your existing Looker content inventory first to size the rebuild.
Scheduled delivery	Metabase subscriptions or Superset alerts and reports	Confirm email and Slack delivery, cadence options and whether reports can be sent to external recipients in your current release. Plan for a separate mail or messaging configuration on your side.
Embedded analytics	Metabase embedding or Superset embedded SDK	Embedding is a core use case for both, but signed embedding, theming and row-level filtering for embedded users differ by edition. Confirm the exact mechanism in the version and plan you select.
Git-based version control	Git repository holding dbt project or Superset asset exports	Looker maps each LookML project to a Git repository. Open-source options version dbt code or exported dashboard definitions in Git, but the review workflow for dashboards is usually less native. Confirm what can be exported and imported in your version.
SSO and row-level access	Superset (database, LDAP or OAuth through Flask AppBuilder) and Metabase paid tiers	Superset supports LDAP and OAuth through Flask AppBuilder. Metabase row and column level permissions and SSO sit in paid Starter and Pro plans, so confirm the tier that covers your access model before design.
Governance and audit	Lightdash with dbt documentation, Superset and Metabase admin roles	Governance depends on your metadata discipline more than the tool. Confirm audit logging, content approval and certification features in each release, since these are not parity items with Looker by default.

Moving LookML models out of Git into dbt metrics or Superset datasets

The first step is to treat your LookML as code you already own. Each LookML project corresponds to a Git repository, and Looker connects to remote providers such as GitHub, GitLab or Bitbucket over HTTPS or SSH, so the model files, views, explores and dashboards definitions can be cloned and reviewed before any migration decision is made. Confirm with your Looker administrator which project branches are in production, whether any content lives only in the Looker UI rather than in Git, and which user-level or model-level access grants are defined in the model files. Those grants do not move automatically and must be recreated in the target platform. Translation is a rewrite, not a file conversion. Views and their dimensions and measures map most directly to dbt models and metrics when Lightdash is the target, because Lightdash reads dbt projects and uses dbt metadata to define dimensions and metrics on top of tables. Explores and joins map to dbt relationships and the model layer that Lightdash exposes. In Apache Superset, the closer equivalent is a physical or virtual dataset written in SQL, with metrics defined on the dataset. Measures that depend on aggregation type, filters or symmetric aggregates need to be re-expressed and tested against known query results, row counts and totals, not assumed to behave the same way. The main losses are predictable. Liquid templating in LookML, derived tables with complex procedural logic, and parameters or templated filters have no one-to-one counterpart and will need to be flattened into SQL, dbt macros or dashboard filters. Ask each target vendor, and test in a pilot, how it handles caching, row-level security and permission inheritance from your identity provider. Build a comparison report that checks a sample of key metrics across both systems over the same date range, and treat any gap in that report as a blocker until the logic is documented and approved.

What a Looker replacement costs over several years

This table separates the cost of staying on Looker from the cost of running an open-source replacement, component by component. Read each row for who is paid, whether the cost is one-time or recurring, and what moves it up or down. Fixed fees are not quoted here because no supplied figures exist, so ask for them in writing.

Cost component	Who is paid or who carries it	One-time or recurring	Main cost drivers
Looker subscription	Google Cloud, under the Standard, Enterprise or Embed edition you hold	Recurring	Edition chosen, number of users, embedded use, contract term. Confirm current fees with Google Cloud or your reseller.
Open-source license	No license fee for the community editions of Apache Superset, Metabase Open Source or Lightdash core	Not applicable for core, check enterprise add-ons	Choice of community or enterprise code paths. Enterprise features such as SSO or row-level security may sit under paid plans or commercial licenses.
Enterprise add-ons	Vendor of the chosen platform, where you need features outside the community edition	Recurring	SSO, row and column permissions, support tier, air-gapped terms. Confirm what each plan includes before you commit.
Hosting and infrastructure	Your cloud account or data center team	Recurring	Number of application nodes, high availability, backups, monitoring, and environments for development and production.
Metadata database	Your cloud account or database team	Recurring	Choice of PostgreSQL or MySQL for Superset metadata, sizing, backup retention and replicas.
Warehouse and query compute	Your data warehouse provider, which often bills for queries directly	Recurring	Query volume, dashboard refresh frequency, caching, and whether Looker's current query patterns move to the new tool.
Semantic layer rebuild (LookML to dbt metrics or Superset datasets)	Internal analytics engineers or an implementation partner	One-time	Number of LookML views, explores and derived tables, and how much business logic lives in Looker code.
Dashboard and content migration	Internal BI team or an implementation partner	One-time	Number of dashboards, scheduled deliveries, embedded content and user-facing filters to recreate and test.
Implementation, hardening and integration	Internal platform engineering or an implementation partner under a fixed-scope agreement	One-time	Identity integration, network design, security review, and any evidence needed for compliance assessments.
Support retainer and upgrades	Internal team or an implementation partner under a retainer	Recurring	Upgrade cadence, severity expectations, and the number of platforms in scope. Ask for response terms in writing.
Internal skills and training	Your staff, plus any training providers	Both	Team familiarity with SQL, Git-based modeling and container operations. Skills gaps usually cost more than software.

What you give up when you leave Looker and how to work around it

Moving off Looker is less about swapping a dashboard tool and more about re-homing a modeling layer, a hosting model and a set of platform services. The cards below cover what changes, what the usual workaround is, and what to confirm with each candidate before you commit to a migration plan.

Single modeling language

LookML lets one team define dimensions, measures and joins in one place, and Looker reads those definitions from a Git repository for each project. Lightdash and Superset do not reproduce LookML directly, so metric logic usually moves into dbt metrics, a Lightdash YAML layer or Superset datasets with virtual SQL. Expect some definitions to be rewritten by hand. Confirm which layer will be the source of truth for each metric before you export anything.

Hosting and uptime ownership

Looker (Google Cloud core) instances are hosted by Google in Google Cloud and are not offered for customer-hosted or multicloud environments. Once you self-host Superset, Metabase or Lightdash, your team or your implementation partner owns patching, backups, high availability and incident response. Ask who on your side is on call, how upgrades are tested against your data sources, and what recovery time your business units require.

Google-specific integrations

Looker is tightly coupled to Google Cloud services, including identity, BigQuery connectivity and managed networking. Those connectors are native in Looker but must be configured by hand in an open-source tool. Check each connector your reports use, including BigQuery and any Google Workspace identity flows, and confirm that the driver or SQLAlchemy dialect is available and supported for your database version. Test query performance on the same warehouse before cutover.

Embedded analytics features

Looker Embed has its own licensing edition and features for signed embedding and white-labeled content. Open-source editions provide embedding capabilities that differ in scope and in how authentication tokens and theming are handled. List the embedded dashboards your customers or internal portals depend on, then test each one against the candidate's embed options, including session handling and filter passing, before you retire the Looker embed.

SSO and row-level security tiers

Some open-source editions keep single sign-on and row or column level permissions behind a paid plan. In Metabase, for example, the free Open Source edition is self-hosted with unlimited users and dashboards, while SSO and row and column level permissions come with the paid Starter and Pro plans. Confirm which features your security policy requires in the free edition, and whether the commercial license terms fit your deployment model, before you design access control.

Analyst learning curve

Analysts used to LookML explores, Looks and the Looker SQL runner will need time with new interfaces, whether that is Superset's SQL Lab and chart builder, Metabase's question builder or Lightdash's dbt-based explore. Plan training sessions, a parallel run period and a shared catalog of approved metrics so that teams do not create conflicting definitions during the transition. Ask each vendor or partner for a sample of the workflows your analysts use most.

How a Looker to open-source migration runs in phases

The sequence moves dashboards, semantic definitions and users off Looker in controlled stages, so each stage closes with evidence that the new platform returns the same answers before Looker access is removed. Because Looker Core is hosted only by Google, the export of LookML and the parallel run carry most of the risk and deserve the most attention.

Inventory dashboards, explores and users
Start by listing every dashboard, Look, explore, scheduled delivery, embed and user group in the Looker instance, along with the database connections each one depends on. Assign each item an owner and a business domain, and mark which ones are used regularly. Ask your Looker administrator for usage history and access logs so unused content can be excluded early. The step is complete when the inventory is signed off by business owners and every item is tagged to keep, rebuild, retire or merge.
Export LookML from the Git repository
Each LookML project is backed by a Git repository that Looker connects to over HTTPS or SSH, so the model files can be cloned from your own provider (GitHub, GitLab or Bitbucket) rather than extracted from the Looker interface. Confirm with your Looker administrator which branch is production, and check for uncommitted changes that exist only in the Looker development mode. The step closes when a complete copy of the production LookML is stored in a repository you control, with a commit hash recorded for the baseline.
Map LookML to dbt metrics or Superset datasets
Translate views, explores, joins, measures and filters into the target semantic layer. Lightdash and dbt-based models are a natural fit for teams that want metric definitions in version control, while Apache Superset works with datasets defined over SQL and virtual datasets. Record each measure's logic in plain SQL and note any LookML feature with no direct equivalent, such as certain Liquid templating or derived table patterns, so the gap is visible. The step closes when every production explore has a documented mapping and a list of open gaps reviewed by the data team.
Pilot with one business domain
Choose a single business domain with a bounded set of dashboards and a willing set of users, such as finance reporting or a single product area. Build the semantic layer, dashboards and access roles for that domain only, and run it with the business owners for a defined review period agreed with them. Use the pilot to test authentication, row-level access and scheduled delivery, and record every defect and workaround. The step is complete when the pilot owners accept the outputs in writing and the open defect list is small enough to plan against.
Run a parallel comparison of query results
For each migrated metric, run the same question in Looker and in the new platform against the same warehouse and time window, then compare totals, filtered counts and groupings. Document every difference, including rounding, timezone handling, null treatment and filter defaults, and resolve it in the semantic layer before sign-off. Because Looker runs only on Google's hosting, this comparison depends on Looker remaining available during the run, so confirm your Google Cloud subscription terms cover the full window. The step closes when each domain has a comparison log with zero unexplained variances.
Cut over users and embedded content
Move users group by group, updating links, bookmarks, scheduled reports and any embedded dashboards in internal portals or customer-facing applications. Confirm that single sign-on, role mappings and data permissions match the Looker configuration before each group switches. Keep a rollback route for each group until its first full reporting cycle has passed without incident. The step is complete when all users are on the new platform, embeds point to the new URLs, and support tickets have returned to the agreed baseline.
Decommission Looker and remove access
Once cutover is complete and rollback is no longer needed, export a final archive of dashboards, models and access logs for your records and retention obligations. Revoke user and service account access, remove Git connections and deploy keys, rotate any database credentials Looker used, and confirm the subscription end date with Google Cloud in writing. The step closes when access reviews show no active Looker users or credentials, and the archive and deletion evidence are filed with your compliance team.

Which Looker alternative fits your situation

Teams that already model data in dbt and want metric definitions to live next to transformations are the closest fit for Lightdash. Lightdash reads dbt projects and metadata, so the semantic layer you move out of LookML can be expressed as dbt models and metrics instead of a separate modeling language. Because the core of Lightdash is MIT licensed, the code outside the enterprise directory can be self-hosted without the commercial license, while the enterprise directory is covered by a separate license.

Model source: LookML files map to dbt models and metric definitions, which need manual translation and review.
Git workflow: Changes to metrics go through the same pull requests your analytics engineers already use.
Licensing: Confirm which features you need sit in the MIT portion and which require the enterprise license.
Hosting: Confirm the deployment method and the supported database warehouse for your environment.
Gaps: Look at how it handles your most complex Looker explores and access rules before you commit.

Confirm that your warehouse and dbt version are supported, and test your three most-used explores against the rebuilt metrics before you retire Looker.

Questions buyers ask before replacing Looker

How much effort does a Looker migration take?

The effort depends mainly on how much LookML logic you have, how many models and explores feed production content, and how many dashboards and scheduled deliveries depend on them. Each LookML view, explore, join and measure has to be understood and rebuilt somewhere else, either as dbt metrics, Apache Superset datasets with virtual SQL, or Lightdash or Metabase models. Teams with clean, well-named models and a small set of dashboards usually have the smaller job. Teams with heavy Liquid templating, access filters and many derived tables have more to map and test. Ask any provider to inventory your LookML repository before quoting, and to list which dashboards and users depend on each explore.

Does LookML convert automatically to another tool?

No. LookML does not convert automatically to dbt metrics, Superset datasets or the semantic models in Lightdash or Metabase, because each platform defines joins, metrics and permissions differently. The model definitions can be exported from Git, since each LookML project corresponds to a Git repository, which gives you a complete source to work from. The conversion is a manual mapping exercise: you translate measures into SQL expressions or metric definitions, check join logic against the warehouse, and reconcile results so that a number on the new platform matches the number in Looker before users switch over.

How long does a pilot take to run?

A pilot runs for as long as it takes to rebuild and validate a representative set of models and dashboards, and that duration depends on model count. A pilot covering two or three core explores with reconciled figures is a different exercise from one covering the full model library. Agree on the pilot scope, the success criteria and the reconciliation method in writing before work starts, so that the timeline reflects the agreed scope rather than an estimate made before anyone has read the repository.

What do the open core licensing editions include?

Lightdash and Metabase both use open core models, so the free edition is not the same as the paid edition. Lightdash's content outside the packages/backend/src/ee directory is MIT licensed, while the ee directory is under a separate license. Metabase's open-source code is AGPL-3.0, while its enterprise directory is under the Metabase Commercial License, and its free Open Source edition is self-hosted with unlimited users and dashboards. Metabase's paid Starter and Pro plans add support, SSO and row and column level permissions, and only its Enterprise plan offers air-gapped deployment. Confirm which features your access model, single sign-on and air-gapped requirements need before choosing an edition, and read the license files directly.

Can our team migrate from Looker without outside help?

Yes, a team with strong SQL skills, Git experience and someone who knows the existing LookML well can do it internally, and some teams prefer that. The harder parts are usually not the software installation but the semantic work: agreeing on metric definitions, reconciling numbers with finance or operations, and rebuilding permissions. Teams often underestimate how much time that takes alongside their normal workload. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure under a fixed-scope agreement, and can cover part or all of that work. Compare an internal plan against a written scope before you decide.

What do we need from our internal staff during the migration?

Your staff need to supply knowledge and decisions, not just access. The main contributions are:

Data owners who confirm which metrics are authoritative and how they are defined.
Engineers who can grant warehouse access, manage the Git repository and review the dbt or SQL changes.
Analysts who validate reconciled reports and sign off on the cutover.
Platform or security staff who own hosting, identity integration and backups in your environment.

Ask any provider to name these roles in the scope, and to estimate how many hours each role will spend per week during the engagement.

What drives the ongoing cost of self-hosting a replacement?

Open-source BI tools have no per-user license fee for the free editions, so the recurring costs are infrastructure, database resources, backups, upgrades and the people who run them. Infrastructure and database costs depend on query volume, cache size and the number of concurrent viewers in your environment. Upgrades and security patches recur, as does support, whether you staff it internally or buy a retainer. Paid editions from Metabase or Lightdash add their own recurring subscription cost. Ask for a quote that separates one-time migration work from recurring operations, and state which upgrades and support hours it includes.

What to confirm with each vendor before you commit

Before you shortlist any replacement for Looker, confirm five things in writing: which edition features cover single sign-on, row-level permissions and embedding; which licence governs each directory of the code you would run; which data warehouses the current release supports; how often new versions ship and how long older ones receive fixes; and whether the feature you need sits in the open-source build or behind a paid tier. Metabase's published plans, for example, place SSO and row and column level permissions in paid Starter and Pro plans, while the free Open Source edition covers the core self-hosted product. Lightdash splits its code between MIT-licensed packages and an ee directory under a separate licence. Treat each of these as a question to answer from the vendor's current documentation, not from memory or a comparison article.

Apache Superset is Apache-2.0 licensed and stores its metadata in PostgreSQL or MySQL, with authentication handled through Flask AppBuilder, so SSO and role mapping are configured in code and settings rather than bought as an add-on. Check that the authentication method you need, whether database, LDAP or OAuth, is documented for the version you intend to deploy, and confirm that your warehouse has a Python DB-API driver and SQLAlchemy dialect. Verify the embedding model you plan to use, including how signed or guest access to dashboards is handled, against the current release notes. Because Looker's semantic layer is LookML in Git, also confirm which semantic layer option (dbt metrics or Superset datasets) each candidate supports for your warehouse.

Run a proof of concept against a copy of your production warehouse before you sign anything. Use a single domain, such as one LookML model with its row-level access rules, and test the sign-on flow, a restricted user, an embedded dashboard and one scheduled report end to end. Record the version tested, the driver versions and any configuration that was needed. Ask the vendor or your integrator to confirm in writing which features the proof of concept depends on, and which of those require a paid edition. The result of this test is more reliable evidence for your decision than any feature matrix, including the one on this page.

How DeployOpen scopes, migrates and supports a Looker replacement

DeployOpen plans and implements self-hosted open-source analytics platforms inside your own cloud accounts, data centers or air-gapped networks, which matters when Looker's Google-hosted model does not fit your residency or hosting requirements. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every LookML model, explore, dashboard, schedule and user group to decide what moves and what is retired.
Confirm which candidate platform (Lightdash, Apache Superset or Metabase) fits your semantic layer, licensing and hosting constraints.
Agree in writing the target hosting environment, identity provider, data sources and deliverables before any build begins.

How we build

Export LookML from its Git repository and rebuild models as dbt metrics or Superset datasets, with the logic reviewed line by line.
Deploy the chosen platform with its metadata store in PostgreSQL or MySQL inside your infrastructure, configured for your authentication method.
Test row-level access, dashboard parity and query results against Looker outputs before any user is moved over.

How we hand over

Document architecture, configuration, access model and semantic layer definitions so your team can maintain them without us.
Deliver runbooks for backups, upgrades and restores, along with a record of which Looker content was migrated or retired.
Run a handover session with your platform, data and analytics owners, and confirm each deliverable against the agreed scope.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
Track new open-source releases and plan upgrades in a change window that your team approves.
Ask any provider for the written support terms, response expectations and what a retainer includes before you commit.