Semantic layers in practice: dbt, Cube, LookML.
A side-by-side look at the three semantic-layer options we keep choosing between, and the constraints that push us toward each.
A semantic layer is the contract between your warehouse and everything downstream that wants a number out of it. Pick well and you spend the next three years iterating on definitions inside a single layer. Pick badly and the same metric ends up reimplemented in four different dashboards, three different reports, and one very confident PowerPoint.
We have shipped each of dbt’s semantic layer, Cube, and LookML into production environments. Each is the right answer to a specific question. None is the right answer to all of them.
The shared problem
Every analytics environment past a certain size accumulates the same failure mode. Revenue is defined three different ways. Active user means something different in product than in marketing. The data team becomes a translation function between teams that all believe they are looking at the same number. A semantic layer is the durable fix: a single place where every metric, dimension and join is declared, tested and exposed.
What “works” looks like
- One definition of every metric, owned by a named person.
- Tests that fail loudly when a definition drifts.
- An exposure surface that downstream tools (BI, notebooks, reverse-ETL, AI) consume from.
- Lineage from raw source through transformation to every metric.
The three contenders below all get you there. The differences are where they put the work, what they assume about your stack, and how they fail.
dbt’s semantic layer
If your team is already running dbt for transformation, the dbt semantic layer is the lowest-friction option. Metrics live next to the models they depend on, in the same repo, with the same tests and the same code review process. The mental model stays clean: SQL is the language of transformation, YAML is the language of declaration.
What we like: metrics-as-code that read like part of the warehouse, not a separate product. Excellent lineage out of the box. The governance surface (exposures, tests, freshness) extends naturally to metrics. Pricing and access scale with the dbt deployment you already run.
What to watch: query performance for ad-hoc consumption is whatever your warehouse gives you, with no caching layer in between. For high-cardinality drill-down across many users, you will feel it.
We reach for this when: the team is dbt-fluent, the consumption pattern is dashboards and scheduled reports against a modern warehouse, and the engineering culture prefers code over configuration.
Cube
Cube is the closest thing to a true serving-layer product. It sits between your warehouse and your consumers, pre-aggregating, caching and serving SQL, REST and GraphQL out of the same metric definitions. For embedded analytics and customer-facing dashboards, this is the one we reach for most often.
What we like: caching and pre-aggregation that turn slow warehouse queries into sub-second responses without the team writing one line of cache-invalidation logic. Multi-source support if your data lives in more than one warehouse. A consumption API that mature web apps can integrate against without bespoke SQL on the application side.
What to watch: another service to operate, secure and version. Metric definitions in YAML/JS live outside your transformation repo unless you intentionally co-locate them. The free open-source edition is feature-rich; the managed cloud is the easiest path if you do not want the operational overhead.
We reach for this when: the consumer is an application (internal or external), the query pattern is high-volume and latency-sensitive, or the warehouse cost of unmediated dashboard traffic would be untenable.
LookML
LookML is the original modern semantic layer and remains, for the organizations already standardized on Looker, the most polished consumption experience available. Its model is opinionated: explore graphs, dimension groups, measure definitions, all expressed in a language designed for it.
What we like: end-user self-service that is genuinely safe, because the guardrails are baked into the model. Strong access control, content management and curation tools. A community of practice that has worked the patterns out over many years.
What to watch: LookML is a Looker-only artifact. If your strategy includes serving Power BI, Tableau, embedded apps and notebooks from the same definitions, you will need either a parallel semantic layer or significant duplication. Pricing is a meaningful line item.
We reach for this when: Looker is the consumption standard for the organization, the priority is self-service depth, and the cost model works.
How we choose
The decision tree we have ended up using, in order:
- Is the primary consumer an application (embedded analytics, customer-facing dashboard, AI agent)? If yes, Cube.
- Is the organization fully standardized on Looker for BI, and likely to stay that way? If yes, LookML.
- Otherwise, dbt’s semantic layer, with the explicit option to put Cube in front of it later if a high-volume consumer arrives.
None of this is a religion. We have run dbt and Cube side by side (definitions in dbt, serving in Cube) when both characteristics were present. The point is that the semantic layer is the contract, durable across years, while the dashboard sitting on top of it is disposable.
The mistake we see most often
Teams pick the tool first, then try to retrofit the discipline. It does not work. A semantic layer is a discipline question (Who owns this metric? What does it mean? Who is allowed to redefine it?) before it is a tooling question. The tool you choose decides where the work lives, not whether you do it.
Put the discipline in place first, even if it lives in a spreadsheet for the first month. Then choose the layer. The right layer is the one whose constraints match your consumption pattern, not the one with the loudest marketing in the room.
