dbt as Cross-Cloud Control Layer
Tristan Handy, CEO of dbt Labs, on dbt’s multi-cloud tailwinds
This is the technical condition that turns dbt from a warehouse add on into a cross cloud control layer. Once Snowflake, Databricks, Google Cloud, and AWS all agree to read and increasingly write the same open table format, teams no longer need to copy the same dataset into multiple systems just to use different compute engines. That makes dbt more valuable because the business logic, tests, lineage, and orchestration can sit above any one cloud instead of being trapped inside it.
-
Before this shift, multi cloud usually meant double writing data, paying twice for storage and pipeline runs, and accepting sync lag and data drift. The whole promise got more real once shared table formats like Iceberg let multiple engines point at the same underlying data files.
-
This matters most for pipeline and transformation vendors. dbt and Fivetran touch a huge share of enterprise datasets, so when they can write data in Iceberg, a customer can ingest in one system, transform in another, and query in a third without rebuilding the data model each time.
-
The competitive implication is that warehouses get less leverage from file format lock in, so they have to win on performance, governance, apps, and bundled workflow. That favors neutral layers like dbt, even as Snowflake and Databricks keep expanding into native transformation, catalog, and orchestration.
From here, the battle moves up the stack. Storage standards are settling first, then pipelines, catalogs, and governance layers will compete to become the default way companies manage data spread across clouds. That is the opening for dbt to own the shared logic layer while the clouds compete underneath on compute and integrated products.