dbt turns warehouse transformations into maintained data products

dbt is a framework and platform for turning raw data into maintained data models. Teams write modular transformation logic, define dependencies, add tests and publish shared metric definitions. dbt Labs completed its merger with Fivetran in June 2026, while dbt continues as an active product. Its relevance to AI is the structured context around data: what a table means, how it was built and which rules it is expected to satisfy.

01 / ProductTransformation logic with a software development workflow

The dbt introduction³ describes models built from SQL select statements, with dbt compiling and running the dependency graph. Instead of copying a large query into several dashboards, a team can separate source cleaning, intermediate business logic and final analytical tables. References between models tell dbt how those pieces depend on one another.

The current documentation describes v2 as the default generation, built in Rust with SQL comprehension and editor features. The original Python-based generation remains maintained as v1. This matters when evaluating installation instructions or migration advice: an older article describing only the Python CLI does not cover the current default experience or its feature availability.

The managed platform adds development, scheduling, continuous integration, documentation hosting and operational features. Local development and open-source runtime options also exist. The company’s merger announcement⁶ distinguishes Fivetran’s data movement from dbt’s transformation and semantic context. Buying dbt does not, by itself, create every upstream ingestion pipeline.

02 / AudienceWho benefits from a shared transformation layer

dbt is useful to analytics engineers and data teams whose SQL logic has become a maintained business asset. It suits work where several reports depend on the same customer, order or subscription definitions. Version control and explicit dependencies become valuable when changing one definition can affect many downstream consumers.

It is also relevant when an AI assistant needs more than column names to answer questions. A schema can reveal that a field is called amount, but not whether it represents an invoice, payment or recognized revenue. Model descriptions, tests and centrally defined metrics give the assistant and human analysts a more useful basis for interpretation.

The Snowflake blueprint and Databricks blueprint explain two possible underlying data platforms. They are often complementary to dbt rather than simple replacements. The architectural question is where transformations execute, how they are orchestrated and where the organization maintains its business definitions.

03 / WorkflowA proposed workflow for subscription metrics

Imagine a subscription business whose finance and product teams report different active-customer totals. This is a proposed workflow, not an audit performed for this article. Start by agreeing on the unit of analysis: an account, subscription, workspace or paying organization. Define the reporting date, time zone and treatment of trials, pauses, cancellations and multiple subscriptions.

Identify the raw sources and their update behavior. Billing events, subscription snapshots and account mappings may arrive at different times. Build staging models that standardize identifiers and timestamps without silently changing business meaning. Preserve the original source keys so a disputed result can be traced back to the operational record.

Create an intermediate model that resolves subscription status at the reporting date. A cancellation scheduled for next month should not necessarily be treated like a cancellation already effective. Use small representative examples to review that distinction with the business owner. The model’s SQL should express the accepted rule, with documentation explaining why it exists.

Add data tests⁴ for the assumptions that make the result usable. Built-in tests cover properties such as uniqueness, non-null values, accepted values and relationships. A custom test can return subscriptions whose effective end precedes their start. A passing test establishes the assertion it checks; it does not prove that the entire metric definition is correct.

Publish the agreed metric through the Semantic Layer⁵ where the account and downstream tools support it. Powered by MetricFlow, the layer centralizes metric definitions and handles supported joins. Define the allowed dimensions and time grain so a request for active customers by region does not accidentally multiply accounts through a one-to-many join.

Review the result against a known reporting period before scheduling it. Compare totals and inspect the specific accounts that changed category. Record the accepted definition, model revision and source freshness. An assistant can help draft SQL or investigate lineage, but the durable deliverable is a reviewed metric whose inputs and exceptions are understood.

04 / PricingPricing includes seats and usage boundaries

The Starter page pairs a per-user rate with a five-seat plan allowance. Confirm the intended seat count and billing arrangement in the actual order rather than interpreting the headline as a flat team price. Successful model builds and queried metrics also have allowances. A seat subscription should not be read as unlimited orchestration or Semantic Layer usage.

The current page prices dbt State separately using daily active target tables. Its billing definition concerns distinct target tables with qualifying skip, clone or test-reuse operations on a day. That is different from simply counting every table in the warehouse. Evaluate the documented billing behavior against the workload’s actual reuse and the infrastructure work it avoids.

AI assistance has its own allowances and consumption terms. The public comparison lists Wizard credits that vary by plan, including trial credits on entry plans. Keep those separate from developer seats and warehouse compute. For the subscription project, forecast scheduled builds, development runs, metric queries and any AI consumption alongside the underlying platform’s charges.

05 / DistinctionsWhat stands out in the data development process

dbt makes analytical logic inspectable as a dependency graph rather than a collection of disconnected reports. A changed customer mapping can be traced to the models and metrics that use it. That helps a reviewer understand the scope of a change before it reaches a dashboard or assistant.

The current SQL-aware engine adds feedback earlier in development. The documentation describes capabilities such as inline errors, autocomplete and tracing definitions across a project. Earlier feedback can reduce unnecessary warehouse round trips, but it does not replace execution against representative data or validation of the business rule itself.

The combination of tests and semantic definitions is especially useful for AI-facing data. Tests express assumptions about the records; metrics express agreed calculations. An assistant can use both as context, while a human can inspect the same definitions. This creates a shared reference that is more durable than repeatedly explaining the metric in a chat prompt.

06 / QuestionsQuestions to settle before scaling the project

Who owns each business definition? Technical ownership of a SQL file is not always the same as authority to change a metric. For active subscriptions, record who can approve the treatment of paused or overdue accounts. A well-tested implementation can still be the wrong business definition if that decision is unresolved.

Which engine, adapters and platform features does the project require? The current v2 experience, maintained v1 tools and open-source distributions have distinct capabilities. Confirm the supported data platform and feature path before planning a migration. Avoid mixing instructions from different generations merely because they use the same dbt command name.

What happens when source data is late? A successful transformation can produce a plausible but incomplete total. Define freshness checks, the expected reporting cutoff and the behavior of downstream consumers when a source misses it. The dashboard or assistant should be able to distinguish the latest complete reporting period from a partially updated one.

07 / DecisionChoose dbt for business logic that needs maintenance

dbt is a strong choice when data transformations and metric definitions need the same discipline as other production code: versioning, review, tests and clear dependencies. Start with a metric that already causes disagreement. Use the project to make its definition and evidence explicit before broadening the model graph.

For subscription reporting, success is a reconciled metric that finance, product and an assistant can use consistently. The code, tests and documentation should make future changes reviewable.