When teams go looking for an open-source alternative to Looker, they usually start by comparing charting tools — which one draws the same dashboards, which one connects to the warehouse, which one is free to self-host. That was the right question a few years ago, and it's the wrong one now. The hard part of business intelligence was never the visualization. It was keeping everyone's numbers consistent, and getting answers to people without a two-week ticket queue. AI has moved the goalposts again: the question isn't only "can I self-host my dashboards," it's "can an agent answer a business question against governed data and get it right."

I want to walk through how I think about leaving Looker for open source today, because it looks different than it did when the standard advice was to bolt an open-source dashboard tool onto a metrics layer and call it a day.

What the old open-source recipe gave away

For years, the way to escape Looker's per-seat pricing and LookML lock-in was a two-part stack: put an open-source semantic layer underneath to define your metrics, and point a separate open-source front-end like Superset at it to draw the charts. It worked, and it was a genuine step up from a proprietary black box — your metric definitions lived in code, in your repo, instead of inside Looker.

The problem is what that architecture gives away. The moment the analytics experience — the place people actually ask questions — lives in a different tool, the semantic layer becomes a component underneath someone else's product. You own the definitions but not the surface. Every improvement to how people interact with data has to happen in a front-end you don't control, and the governed model you worked hard to build is reduced to a data source it queries.

That was a tolerable trade when the front-end was "a dashboard." It's a bad trade now that the front-end is becoming an AI agent. An agent that constructs its own queries against ungoverned tables will confidently return numbers that don't match anyone's definition of the metric. The semantic layer isn't the thing you feed to the dashboard anymore. It's the thing that decides whether the agent can be trusted at all. Swapping Looker for Superset doesn't solve that — it just changes which front-end sits on top.

Open source, at the foundation

Cube Core is the open-source semantic layer at the center of this. It's Apache 2.0, it's the original Cube project, and it does exactly what a semantic layer should: one governed definition of every metric, modeled in code, versioned in git, enforced no matter who — or what — is asking. Unlike LookML, those definitions aren't trapped inside a proprietary BI tool; you self-host Cube Core, you own it, and it sits on top of your warehouse rather than replacing it. Snowflake, BigQuery, Redshift, and Databricks stay where they are; Cube models the business logic on top and makes the same governed metrics available everywhere.

That open-source foundation is the part that doesn't change. What changed is what we built on top of it.

From a component to a platform

Cube is the agentic analytics platform built on that semantic layer. Instead of handing your governed model to Looker — or to an open-source dashboard tool standing in for Looker — the analytics experience lives on top of the model directly:

  • Analytics Chat. People ask questions in plain language and get answers grounded in the semantic model — the agent uses your team's definition of "active customer" instead of inventing one from column names.
  • Workbooks and dashboards. The exploratory and reporting surfaces that used to require a second tool, sitting on the same governed definitions so a number means the same thing in a chat reply and a scheduled report.
  • A model that agents can reach. The same governed layer is exposed to external agents over MCP, so an assistant in the tools your team already uses answers from the model rather than guessing against raw tables.

The through-line is that the semantic layer stopped being the product and became the reason the product's AI can be trusted. Your data team's governed definitions stay intact, and the agent constructs ad-hoc calculations on top of them at query time. That resolves the tradeoff every BI stack has always forced — lock everything down and nobody uses the tool, or open it up and end up with fifteen definitions of "churn." You get governed and flexible at the same time, which is the whole reason to put a real semantic layer underneath instead of treating it as a metrics API for Looker.

The same foundation serves internal BI and embedded

One more thing both Looker and the open-source-dashboard recipe make hard: shipping analytics to your own customers. If your BI experience lives in a separate front-end, embedding it in your product means either iframing someone else's UI or rebuilding everything from the API — and Looker's embedded pricing turns that into a line item that scales with every customer you add.

Because the platform is built on the semantic layer rather than beside it, the same governed model powers both internal business intelligence and analytics embedded inside your product. Multi-tenancy, row-level security scoped to each customer, and query performance under load are part of the foundation, not a second integration project. One model, modeled once, serves the dashboards your data team uses on Monday and the analytics your customers see inside your app — governed the same way in both places.

Where this leaves the open-source Looker question

The reason to leave Looker for open source was never just the license. It was ownership: of your metric definitions, of your data, of the tool your business runs on, without a per-seat meter or a black box you can't inspect. That reasoning holds. What's changed is that owning the semantic layer is now the high-leverage place to stand, because it's what determines whether the AI layer on top of it produces trustworthy answers. An open-source dashboard tool pointed at a metrics API gives you the license without the leverage.

So if you're evaluating the open-source route off Looker, I'd start from the model, not the charts. Cube Core is open source and stays that way; Cube is the platform that turns it into an AI-native analytics experience your team and your customers can actually rely on. You can self-host the core, model your metrics in code, and see how governed answers hold up against an agent's questions before you commit to anything.

Try it against your own data — start with Cube, or read how the semantic layer fits the rest of your stack.