dbt as Multi-Cloud Control Point
Tristan Handy, CEO of dbt Labs, on dbt’s multi-cloud tailwinds
This dynamic shows that dbt is moving from useful add on to contested control point. Snowflake, Databricks, and the cloud platforms all want dbt close because it helps customers turn raw tables into trusted business tables, but they also want to own that workflow inside their own stack. dbt’s edge is that the business logic, tests, metadata, and scheduling can sit above any one warehouse, which matters more as large companies run more than one data cloud.
-
In practice, the warehouse vendors are both partner and rival. Databricks has a native dbt task inside Lakeflow Jobs, while also pushing its own SQL and Python pipeline products. Snowflake supports managed dbt project workflows through Snowflake CLI, while building more native semantic and analytics layers on top of warehouse data.
-
dbt wins when one company has Snowflake for BI workloads, Databricks for ML or lakehouse workloads, and cloud native tools around them. That is a common enterprise setup. dbt Cloud sells the shared workflow around SQL models, tests, docs, CI, scheduling, and governance, instead of forcing each team to rewrite the same logic in every platform.
-
Apache Iceberg makes this more concrete. Once major data clouds can read the same table format, the hard part shifts upward from storage to control. The valuable layer becomes the place where teams define metrics, lineage, freshness checks, and production workflows. That is why dbt is expanding into catalog, orchestration, and observability.
The next phase is a fight over who owns the everyday operating system for data teams. Platform vendors will keep bundling transformation into the warehouse, but multi cloud architectures and open table standards give dbt room to remain the neutral layer where business logic lives once and runs anywhere. That pushes dbt further toward being the control plane, not just the transformation tool.