dbt Labs builds software that lets data teams transform raw data inside a cloud warehouse into clean, reliable datasets ready for analysis. The company’s core product, dbt (short for “data build tool”), has become the standard tool for writing, testing, and documenting the SQL and Python code that turns messy source data into the tables and views that power dashboards, reports, and machine learning models.
Where dbt Fits in the Data Stack
Modern data teams typically follow an ELT workflow: extract data from source systems (your CRM, payment processor, ad platforms), load it into a cloud data warehouse, then transform it into something useful. dbt handles that last step. It doesn’t move data between systems. Instead, it runs transformations directly inside your warehouse, where the data already lives.
In practice, this means an analyst or engineer writes SQL select statements that define how raw tables should be joined, filtered, aggregated, and reshaped into final models. dbt compiles those statements, runs them against your warehouse, and materializes the results as tables or views. It also handles dependency ordering automatically, so if model B depends on model A, dbt builds A first.
dbt connects to virtually every major data platform. Snowflake, BigQuery, Databricks, Redshift, and Microsoft Fabric are among the most common, but the supported list runs to over 50 platforms, including Postgres, Apache Spark, Teradata, DuckDB, Starburst/Trino, and many others through community-maintained adapters.
What Makes dbt Different From Writing Raw SQL
Teams have always written SQL to transform data. What dbt adds is a framework around that SQL that borrows from software engineering. Every transformation lives in a version-controlled file, typically in Git. Changes go through code review before merging. Automated tests check whether a column has null values, whether a join introduced duplicates, or whether a value falls outside an expected range. Documentation lives alongside the code, so anyone on the team can look up what a table contains and how it was built.
This structure matters because data pipelines tend to break silently. A column gets renamed upstream, a join condition goes stale, and suddenly a dashboard is showing wrong numbers with no error message in sight. dbt’s built-in testing and documentation make those problems visible before they reach the business.
dbt Core vs. dbt Cloud
dbt Labs offers two versions of its product. dbt Core is the open-source command-line tool, distributed under the Apache 2.0 license. Anyone can install it, run it locally or on their own infrastructure, and use it for free. It’s best suited for small, highly technical teams comfortable managing their own deployment and scheduling.
dbt Cloud is the managed commercial product, and it’s where dbt Labs makes money. It adds a browser-based development environment, job scheduling, a semantic layer for defining business metrics centrally, and collaboration features that make dbt accessible to larger teams. The pricing breaks down into four tiers:
- Developer (free): One seat, 3,000 successful model builds per month, one project. Good for individual learning or prototyping.
- Starter ($100 per user per month): Up to five seats, 15,000 model builds per month, API access, basic versions of the semantic layer and dbt Copilot (an AI code-generation assistant).
- Enterprise (custom pricing): 100,000 model builds per month, up to 30 projects, advanced governance features like dbt Mesh, priority support with SLAs, and implementation assistance.
- Enterprise+ (custom pricing): Everything in Enterprise plus PrivateLink, IP restrictions, rollback capabilities, and unlimited projects for organizations with strict security requirements.
The Semantic Layer
One of dbt Cloud’s more distinctive features is the semantic layer, which lets teams define business metrics (revenue, churn rate, average order value) in one central place rather than redefining them in every dashboard tool. Once a metric is defined in dbt, any connected BI tool or application queries that same definition, so “monthly recurring revenue” means exactly the same thing whether someone pulls it in Looker, Tableau, or a custom internal tool.
This solves a common frustration in data teams: two departments build their own dashboards, use slightly different filters, and arrive at different revenue numbers. The semantic layer eliminates that drift by making dbt the single source of truth for metric logic.
dbt Mesh for Large Organizations
As companies scale their data operations, a single dbt project can grow into thousands of models maintained by dozens of teams. dbt Mesh is an architecture that lets organizations break one monolithic project into multiple interconnected projects, each owned by a different team.
Mesh introduces several governance tools. Model contracts enforce data structure standards, specifying column names and types so that if a model violates its contract, the build fails before bad data reaches downstream consumers. Access modifiers control visibility: a model can be marked private (only usable within its own group), protected (usable within the same project), or public (available to any project in the organization). Cross-project references let one team’s project depend on another team’s public models without copying code or data.
Model versioning lets teams ship changes incrementally. You can publish a new version of a model while keeping the old version available, giving downstream teams a migration window instead of a forced, breaking upgrade.
The Analytics Engineering Role
Beyond its software, dbt Labs is closely associated with defining an entirely new job title: analytics engineer. Before dbt gained traction, data teams typically split into data engineers (who built pipelines and infrastructure) and data analysts (who wrote queries and built dashboards). The transformation work in between often fell through the cracks or got assigned to whichever team had bandwidth.
Analytics engineers fill that gap. They transform, test, deploy, and document data, producing clean datasets that empower analysts and business users to answer their own questions. The role applies software engineering practices like version control, continuous integration, and code review to analytics code. An analytics engineer thinks about problems like whether a single well-designed table can answer an entire category of business questions, or what naming conventions make a warehouse intuitive to navigate.
The role has become common enough to appear as a standalone job title at companies across industries. dbt Labs didn’t just build a tool; it shaped how organizations structure their data teams.