Centralizing Metrics in dbt Semantic Layer
Julia Schottenstein, Product Manager at dbt Labs, on the business model of open source
Putting metrics inside dbt is a bid to make dbt the control plane for business logic, not just the tool that builds tables. The practical issue is that teams already define joins, tests, and source logic in dbt, then often redefine revenue, churn, or CAC again in Looker or another BI tool. Keeping metrics with transformations turns one codebase into the place where raw data gets cleaned, business rules get encoded, and downstream tools read the same definitions.
-
The workflow split is the core pain point. dbt handles batch transformations that create stable tables ahead of time, while metrics are often calculated at query time for a chosen date range or segment. If those live in separate systems, every new dashboard or notebook risks recreating the same logic differently.
-
The main alternative is the BI owned model, best represented by LookML in Looker. That works well inside one BI product, but it ties definitions to that interface. dbt pushed the opposite idea, define metrics once in code, then expose them across BI tools, notebooks, catalogs, and later AI applications through a shared semantic layer.
-
This also became strategic for dbt as the market matured. dbt launched its Semantic Layer in October 2022, and by 2025 the company was expanding beyond transformations into cataloging, orchestration, and observability to defend its position as the place where data teams define trusted business metrics. Newer players like Cube and Preql are chasing the same control point from different angles.
The next step is that metrics stop being just dashboard inputs and become the definitions that power AI answers and automated workflows. If that happens, the winner will be the system that owns reusable business meaning across every tool, and dbt is trying to make its transformation layer the natural place that meaning lives.