Unifying dbt Core and Cloud
Tristan Handy, CEO of dbt Labs, on dbt’s multi-cloud tailwinds
This is the core monetization problem for an open source company that became a workflow platform. In many data teams, Core users write and run transformation code locally with Git and their own infrastructure, while Cloud users rely on browser based development, CI, scheduling, docs hosting, and governed environments. When those paths diverge, one company ends up with two ways to build the same data models, which slows collaboration and makes Cloud adoption feel like a reset instead of a natural upgrade.
-
Core is the open source compiler and framework where teams define business logic in SQL and macros. Cloud sells the surrounding workflow, including the IDE, CI, scheduler, docs, semantic layer, and enterprise controls. The friction comes from splitting the language from the day to day collaboration surface.
-
dbt historically tried to solve this by pushing teams to move everyone onto Cloud, but large companies rarely standardize that cleanly. Many run multiple warehouses, mixed tooling, and separate analyst and platform teams, so hybrid Core and Cloud usage is the normal state, not a temporary edge case.
-
The broader strategic backdrop is that Snowflake, Databricks, and newer orchestration tools are all trying to absorb more of the transformation workflow. If dbt makes Core and Cloud feel like one continuous system, it keeps the open source community attached while giving enterprises a cleaner path to pay for governance and scale.
This is heading toward a model where local and managed development look interchangeable, much like Git and GitLab. The winning version of dbt is not one where Core disappears, but one where a team can start free, add managed workflows as complexity rises, and keep the same project, standards, and habits the whole way up.