User Pull Built dbt's Business Model
Diving deeper into
Julia Schottenstein, Product Manager at dbt Labs, on the business model of open source
It's very common for people to say, "I won't work at a company that doesn't use dbt,"
Analyzed 4 sources
Reviewing context
dbt became a hiring filter because it turned messy SQL work into a shared software workflow that people did not want to give up. Instead of analysts editing fragile queries in scattered tools, teams define transformations as code, test them before they run, track changes in Git, and document what each table means. That makes day to day analytics faster, safer, and much less dependent on tribal knowledge.
-
This kind of user pull is unusual in data infrastructure, where buyers are usually managers and platform teams. dbt first won individual analytics engineers with open source, then sold companies on dbt Cloud to make collaboration, browser based development, and governance work across dozens or hundreds of users.
-
The closest comparison is GitLab for analytics. Core dbt is the free standard that teaches teams to work a certain way. The paid product monetizes the hard parts that show up at company scale, shared environments, orchestration, cataloging, observability, and making less technical analysts productive without local setup.
-
That user love also explains why Snowflake, Databricks, and newer workflow tools are all trying to absorb dbt's job. Whoever owns the layer where teams define business logic and metrics controls a sticky daily workflow, and that workflow can expand into adjacent products over time.
Going forward, dbt's advantage is not just transformation code, it is being the default working style for analytics teams across clouds and across skill levels. If it keeps turning analysts into repeat users and employers into standardizers, it can stay the control point even as warehouses and adjacent tools bundle more of the stack.