Customer-Hosted Looker Alternatives: What You Can Run in Your Own Infrastructure

If you need BI that runs on infrastructure you control, the realistic Looker replacements are: Lightdash if your models already live in dbt, Metabase if you want the fastest path to something people will actually use, Apache Superset if you want the most chart types and free row-level security and can absorb the operational load, Cube plus a visualization layer if the semantic model matters more than the dashboards, and GoodData if you need a commercial vendor with a real modelling language that deploys into your own Kubernetes. Evidence and Rill are worth a look if your team would rather write files than click through a UI. Grafana is excellent for operational and time-series dashboards and a poor fit for business exploration.

The second thing to know before you start comparing: none of these read LookML. Looker's customer-hosted deployment belongs to Looker (original). Looker (Google Cloud core), the version Google is building on, runs in Google's cloud, which is why teams with a "data stays in our network" requirement end up on this search in the first place. Whichever tool you pick, you are not migrating dashboards, you are migrating a semantic layer. Budget accordingly: the dashboards are a week, the model is a quarter.

"Customer-hosted" means three different things

Sort out which one you actually need, because it eliminates candidates fast.

Your cloud account, vendor license. You run the containers in your VPC, the vendor charges per seat or per core. Data stays in your network. This is what most people mean.

On-premise or air-gapped. No outbound internet, or tightly restricted egress. This kills anything with a mandatory cloud control plane, anything that phones home for license validation on a short interval, and any AI feature that calls a hosted model. Check the license-check behaviour specifically: some tools degrade to read-only when they cannot reach the licensing endpoint.

Open source you run yourself. No vendor at all. The cost moves from a license line to a headcount line. Someone owns upgrades, backups of the application database, the reverse proxy, SSO, and the 9am "dashboards are slow" pages.

There is also a hybrid worth naming: vendor-managed control plane, customer-managed data plane. Query execution and results stay in your network, orchestration does not. If your requirement is contractual rather than technical, read carefully where cached result sets, scheduled export attachments, and alert bodies live. Those three are the usual leaks, and they are the ones auditors ask about.

The candidates

Licenses and edition boundaries move. Verify both before you commit, because the feature that migrates into the paid tier is usually the one you need: row-level security, SSO, or running more than one instance.

The migration cost is the model, not the charts

Two concrete things break, and they break quietly.

Symmetric aggregates. In Looker, joining orders to order_items and summing orders.total still gives the right number, because Looker rewrites the aggregate to deduplicate the fanned-out rows. Almost nothing else does this. Port that same join to Superset or Metabase naively and every order total is multiplied by its line-item count. The number looks plausible, which is the dangerous part. Fixes: aggregate at the correct grain in a dbt model and expose that, or use a tool that understands join cardinality in its model layer. Cube declares the relationship explicitly and handles the grain; Lightdash inherits whatever your dbt project does, which means the burden lands in dbt where it arguably belongs. Whatever you choose, write a test query with a known-correct answer and run it on day one, not in week six.

Access filters. Looker's access_filter binding a field to a user attribute is how most teams do per-customer or per-region isolation. Equivalents differ sharply, and this is where the free-versus-paid line bites: Superset ships row-level security in the open source core, defined as a SQL clause bound to a role. Metabase's data sandboxing is a paid-edition feature, so the free self-hosted version cannot do it. Cube enforces it through a security context carried in a signed JWT, which is also the cleanest option if you are embedding.

Beyond those: persistent derived tables become dbt models or materialized views, Liquid templating has no equivalent anywhere and has to be rewritten, and while Looker's API can export your content inventory, no destination tool has an importer for it. Treat the export as an audit. Most teams find that a third of their Looks have not been opened in a year and rebuild only what survives that cut.

Where the simple answer breaks

Embedding for customers. If you are putting analytics in your own product, the shortlist changes. You want signed tokens with locked parameters, per-tenant filtering enforced server-side, and a theming story. Metabase interactive embedding and Superset's embedded SDK with guest tokens both work; Cube is the most natural fit if you are building the UI yourself anyway. Verify that the embedding feature is in the edition you are licensing, not one tier up.

Concurrency. Superset's default configuration is a demo configuration. Real deployments need Celery workers, Redis, a results backend and a warmed cache, or dashboards with a dozen charts will time out under twenty simultaneous users. Metabase is easier to stand up and harder to scale sideways. Load-test with your actual dashboards and your actual concurrency before signing anything.

Governance and promotion. The thing teams miss most about Looker is git-backed LookML: pull requests, dev branches, a real diff. Only the code-first tools give you that. In Metabase and Superset, content lives in an application database, and moving it between dev and production means serialization exports or import zips that are workable but never enjoyable. If review workflow is why you liked Looker, weight Lightdash, Cube and Evidence heavily.

A one-week evaluation that tells you the truth

Point the candidate at your real warehouse, not a sample dataset. Rebuild your three most-used dashboards and your one most-contested metric. Run the fanout query and check the number by hand. Configure SSO and confirm group-to-permission mapping. Set up row-level security and log in as a real restricted user. Load-test at your peak concurrency. Then do the least fun test: upgrade to the next version, and restore the application database from a backup into a clean environment. A BI tool you cannot upgrade or restore is a BI tool you will be replacing again in eighteen months.

What no hosting model fixes

Every tool above connects to your warehouse and to modelled sources. That covers "what happened" well. It does not cover "why", because the why is usually a sentence somewhere else: a customer's reply in an email thread, a support ticket that never got tagged, a Slack message where someone agreed to pause a rollout. That evidence is outside what a BI tool of any hosting model can see, which is not a criticism of Looker or its alternatives, just a boundary.

Skopx sits on the other side of that boundary. It connects to nearly 1,000 tools plus databases including PostgreSQL, Snowflake and ClickHouse, and answers questions across them with citations back to the source message, ticket or row. Describing a view in a sentence gives you an internal app that reads across those tools and, where you want it, exposes a button that takes an action after a confirmation. It is not a replacement for your BI layer. It is the layer that reads the things your BI layer was never connected to.