dbt owns business logic authoring

Diving deeper into

Julia Schottenstein, Product Manager at dbt Labs, on the business model of open source

Interview
We don't need another layer. In fact, that's the last thing we need.
Analyzed 2 sources

This reveals dbt’s real wedge, owning the place where business logic is written, not adding another tool for people to manage. If metrics live beside transformations, the same definition of revenue, CAC, or retention can feed a dashboard, notebook, or catalog without being rebuilt in each BI tool. That makes dbt harder to replace, because it becomes the system where teams codify how the business actually works.

  • A separate metrics product sounds clean in architecture diagrams, but in practice it means analysts maintain SQL models in one place and metric definitions in another. The interview ties this directly to the pain of rebuilding the same metric in LookML or other BI specific layers, which creates drift and extra work.
  • The deeper competitive point is neutrality. Warehouses like Snowflake and BI tools like Looker can offer transformation or semantic features, but many enterprises run multiple warehouses and multiple BI tools. Putting logic in dbt lets one team define it once, then reuse it across storage and consumption layers.
  • This also explains why dbt keeps expanding outward. Recent research shows dbt moving into cataloging, orchestration, and observability as Snowflake, Databricks, and newer startups all try to capture the same workflow. Metrics are central because they anchor the highest value definitions inside that broader workspace.

The market is heading toward fewer standalone layers and more bundled workflows around the authoring point for data logic. If dbt keeps winning that authoring point, it can remain the control plane above warehouses and loaders, while monetizing the surrounding workflow tools that make those definitions reliable, governed, and easy to ship.