dbt as Application Infrastructure
Julia Schottenstein, Product Manager at dbt Labs, on the business model of open source
This points to dbt becoming application infrastructure, not just analytics plumbing. Once teams can refresh warehouse models every 15 minutes or faster, test them, document them, and reuse the same business logic everywhere, the warehouse starts acting like a serving layer for dashboards, internal tools, and some customer facing software. dbt sits in the middle as the place where analysts and data engineers encode the rules that the app actually runs on.
-
The practical shift is from reports to workflows. In the modern data stack, Fivetran loads raw data into Snowflake or another warehouse, dbt turns it into trusted tables, and tools like Census push those outputs back into operational systems. That same loop can also feed product experiences directly from warehouse data.
-
This only works on the edges of software, not for every app. dbt's own view is that warehouses are usually a poor fit for core transactional software, but they work well for data heavy surfaces like admin dashboards, segmentation, scoring, and status views where fresh data matters more than millisecond writes.
-
dbt's strategic advantage is neutrality. Because many large companies use more than one warehouse and more than one BI tool, they want transformation logic and metrics defined once, outside any single vendor stack. That makes dbt the control point for business logic even as Snowflake, Databricks, and others push deeper into the same workflow.
The next step is a faster, tighter warehouse loop. As ingestion, transformation, and sync move closer to real time, more B2B software will read from warehouse defined data models first, then write actions back into apps. That expands dbt from a transformation tool into the system that defines how data products behave across clouds, teams, and interfaces.