dbt as multi-cloud control plane

This is the core argument for why dbt wants to own the workflow layer instead of just one transformation tool. In a real enterprise, one team may run finance data in Snowflake, another may build ML pipelines in Databricks, and a third may still use BigQuery or Redshift. If the SQL definitions, tests, lineage, and catalog only exist inside one cloud, every migration or second cloud adoption means rebuilding the same logic and losing consistency.

• Business logic here means the reusable rules that turn raw tables into metrics and reports, like how revenue is defined, which customers count as active, or how refunds are netted out. dbt packages those rules in code and metadata above the warehouse so the same definitions can run across clouds instead of being trapped in one vendor specific layer.
  1 sacra 2 sacra
• This same pattern shows up in governance. Immuta sells a separate policy layer because large customers often use Snowflake, Databricks, Starburst, Redshift, and BigQuery at the same time, and they want to define access rules once and push them everywhere. The buyer need is less best database, more one control surface across a messy estate.
  6 sacra
• Apache Iceberg makes this much more practical because it gives different engines a shared table format. Databricks backed that shift with its June 4, 2024 agreement to acquire Tabular, and both Databricks and Snowflake now support Iceberg tables. That weakens storage format lock in and makes the workflow and metadata layer more strategically valuable.
  1 sacra 3 snowflake 4 databricks 5 prnewswire

The next battleground is who becomes the neutral control plane for a multi cloud data estate. Snowflake and Databricks will keep bundling more first party tooling, but the opening for dbt is to become the place where teams define models, tests, lineage, and orchestration once, then carry that operating system across every warehouse and lakehouse they adopt.