dbt expansion from team to enterprise
Julia Schottenstein, Product Manager at dbt Labs, on the business model of open source
This expansion path is what turns dbt from a useful team tool into an enterprise standard. One team proves that dbt can make analysts and analytics engineers faster without handing every change to a central data engineering group, then the head of data can roll the same workflow across many teams, warehouses, and environments. That matters because large companies often have multiple data teams and more than one warehouse, so the same governance layer can spread inside the account.
-
dbt usually lands bottoms up with practitioners, but larger rollouts are sponsored by heads of data platform who want one system for documentation, testing, reviews, scheduling, and security across hundreds or even 1000 plus analysts and analytics engineers.
-
The expansion is not just team by team. It can also move warehouse by warehouse. dbt’s vendor neutral position is valuable because large enterprises often run Snowflake for some workloads and Databricks for others, and do not want to rewrite business logic in each stack.
-
This is also why dbt monetizes workflow and control, not the SQL framework itself. The open source core gets one team started, then Cloud adds the browser IDE, CI checks, scheduler, docs, governance, and enterprise controls that make an org wide rollout manageable.
Going forward, dbt’s best path is to become the common control layer above fragmented data stacks. If it keeps winning the first team and then standardizing the workflows around quality, collaboration, and cross cloud business logic, expansion inside large enterprises becomes less like upsell and more like internal consolidation.