dbt as Neutral Analytics Control Plane
Julia Schottenstein, Product Manager at dbt Labs, on the business model of open source
dbt Labs is strongest when it sits above the warehouse fight, because that lets it sell the same workflow and governance layer to every data team no matter which cloud they picked. In practice, that means writing models, tests, schedules, and metric definitions once, then running them across Snowflake, Databricks, BigQuery, and others, instead of forcing customers to rebuild their analytics process every time infrastructure changes.
-
The partnership logic is simple. Warehouses want more compute and storage spend, and dbt makes those warehouses more useful by turning raw tables into trusted business data. That creates coopetition, where Snowflake and Databricks may build adjacent features, but still want dbt in deals because customers already use it and it drives more workload onto their platforms.
-
Being neutral also protects dbt from the trap that hit other data stack layers. Connector vendors like Fivetran can get squeezed when platforms or SaaS apps build native integrations themselves. dbt is harder to displace because it owns the shared logic of how a company defines revenue, customers, and product metrics, which has to work across tools, not just inside one vendor stack.
-
This position gets stronger as data estates become more mixed. dbt has been building cross platform mesh, Iceberg support, and semantic layer support across major warehouses. The common thread is keeping business logic and metadata in a control plane above the storage engine, so a company can change clouds without rewriting its analytics operating model.
The next step is for dbt to become the default control layer for multi warehouse analytics, where teams manage transformation, governance, and metric definitions once and push them everywhere. If that happens, warehouse vendors keep competing on infrastructure, while dbt becomes the neutral system that tells the business what its data means.