dbt as semantic control plane

Putting metric definitions in the BI tool makes the dashboard product the owner of business logic, which is why dbt is trying to move that logic down into the transformation layer. In practice, that means a team defines revenue, CAC, or retention once next to the SQL models that shape raw warehouse data, then reuses the same definition in dashboards, notebooks, catalogs, and apps instead of rebuilding it inside each reporting surface.

• Looker made this pattern famous with LookML, a proprietary modeling language tied to Looker itself. That works if Looker is the only place a company reads metrics, but it creates rework once the same KPI needs to appear in another BI tool, a notebook, or a data product.
  1 sacra
• dbt’s pitch is that metrics belong with transformations because both are part of the same workflow. Analysts already use dbt to turn messy source tables into clean business tables with tests, documentation, and version control, so adding metric definitions there creates one governed layer instead of two separate modeling systems.
  1 sacra 2 sacra
• This has become more important as companies run multi-cloud and multi-tool stacks. dbt’s broader strategy is to be the control plane above warehouses and BI tools, where business logic and metadata live once and stay portable across Snowflake, Databricks, and different consumption layers.
  2 sacra 3 sacra

The direction of travel is toward a shared semantic layer that sits above any single dashboard product. If dbt keeps winning that layer, it becomes harder to replace because the sticky asset is not the chart, it is the canonical definition of the business itself.