dbt v2: ten years from SQL tool to data platform

Last week's dbt Summit marked the general availability of dbt v2, roughly ten years after dbt's first releases in 2016. That milestone gave me the idea to revisit its major releases and use that history to put the latest announcements in perspective. I wanted to understand how dbt got here, where it stands today, and the role it and Fivetran are positioning themselves to play in an evolving data stack.

So I built a small app that walks through that history, release by release, with examples based on the classic Jaffle Shop project. Alongside the features each release brought, it tracks the product catalogue and surrounding ecosystem. It gave me a way to connect the tool I started using years ago with today's announcements around compute, charts, and business context for agents.

Explore the dbt history app.

Watch the walkthrough:

How dbt's role kept expanding

The early releases take us back to 2016: dbt 0.1.1 was uploaded to PyPI that April. My own experience started in 2018, when I wrote about introducing dbt into client projects. I was trying to move beyond Python ETL scripts that were becoming difficult to maintain, and two clients gave me room to experiment.

Reading that article again, the appeal is clear: SQL models that reused business logic, testing as part of the workflow, and a focused tool that fit alongside the rest of the stack. I explicitly connected dbt to the Unix philosophy of tools doing one job well and working together. Modularity was part of what drew me to it.

Reusable macros are a good example of that appeal. You could take an operation repeated across models, give it one definition, and call it where needed. The app's Jaffle Shop macro walkthrough makes that change concrete: it shows the shared logic in a macro and how a model uses it.

But the history also shows dbt taking on more responsibility for how people understand and use their data.

With v0.11.0, dbt introduced generated project documentation, including table and column descriptions in its project metadata. To me, that's a useful early step to revisit: the project was becoming a place to explain the data being built.

The Semantic Layer extended that responsibility into how metrics are defined and consumed. At Coalesce 2023, dbt announced general availability of the revamped Semantic Layer powered by MetricFlow, following its acquisition of Transform. The ambition was to maintain metric definitions centrally and make them available through integrated analytics tools.

Then Fivetran and dbt Labs completed their merger on June 1, 2026, bringing data movement and transformation into one company.

Seen together, those shifts help explain the position they're in today. They participate in getting data into the platform, modeling it, documenting it, and defining how it's measured. That gives them several places from which to extend their role as agents become another consumer of that data.

What the latest announcements add up to

The Summit recap states the shared thesis behind the announcements:

the data foundation that makes analytics trustworthy is the same foundation that makes AI trustworthy

That helps explain why the work already happening around data quality, definitions, and metadata is so central to their AI strategy.

The engine is an important part of that direction. According to dbt's Summit recap, v2 brings the work developed through Fusion into one Rust-based engine, with two distributions: dbt and dbt-oss.

The fuller dbt distribution includes SQL comprehension and is free to use, with optional paid features such as dbt State. dbt-oss contains the Apache 2.0-licensed components. The earlier dbt Core line continues as dbt v1.

Around that engine, the announcements address decisions that reach across more of the platform:

The app's product catalogue brings the offerings together at the selected release. With dbt v2 selected, it's a useful way to see the breadth of the portfolio behind these announcements and how far it reaches beyond the transformation engine.

I'd been asking a version of this strategic question after Coalesce in October 2022, when I wrote dbt Inside: setting the data platform standard. My interpretation then was that Python support and the semantic layer could help dbt become a standard that other parts of the platform would build around. I was also questioning what that expansion meant for modularity, replaceability, and avoiding vendor lock-in.

Today's announcements give me more concrete pieces to examine through that lens. My reading is that dbt and Fivetran want to connect more of the path from source data to the systems that consume it. They already have a role in preparing that data. These additions give them a larger role in deciding how it runs, how it's presented, and how agents interpret it.

The Summit recap's description of Context Layer makes that reach explicit:

That's what Fivetran Context Layer is built for: turning every source your business runs on—both structured sources like dbt and unstructured ones that BI tools never touched—into context for the AI tools you're already using, from Claude to Slack.

The companies frame this as open data infrastructure, with choices across storage, compute, and other layers. So I wouldn't read the expansion as a claim that every component must come from them. I read it as an attempt to make their ecosystem a more complete option, while continuing to work with the rest of the stack.

The wider ecosystem view puts that expansion alongside other tools across the layers of the data stack. Looking at both views together helps frame the strategic question: where are dbt and Fivetran offering another component, and where are they trying to connect several parts of the platform?

That changes the questions I'd ask when evaluating the offerings. Each product needs to be useful on its own. But the broader strategy also depends on what gets easier when you use them together, and whether your definitions and context carry across those connections.

The connections are where I'd look for proof

I've worked on those connections myself. In January 2023, I wrote about building a semantic layer with dbt Metrics, Cube, and Droughty for the discursus project. Using the metrics approach available at the time, I defined semantics in dbt, used Droughty to generate Cube definitions from warehouse schemas, and exposed them through Cube. The practical concern was the effort and risk of carrying definitions across tools with different syntaxes.

That experience is why one detail in dbt Charts caught my attention. I expected to be able to build charts on top of metrics already defined in the dbt Semantic Layer.

As of September 24, that integration remains an open feature request, planned but unscheduled. The issue explains that boards currently use SQL, which can lead to metric definitions being repeated and drifting apart.

That's a practical test of the broader direction. If I've already defined a metric, I want the next product in the ecosystem to use that definition. Having to restate it adds another place to maintain the same business logic.

Lake Compute raises a different test. Its documentation positions it for transformations that don't need the full capabilities of a distributed warehouse, running either alongside a warehouse or as the primary adapter for a new project. I can understand the value of choosing compute per model. I'd still want to see which workloads justify the SQL adjustments, setup, and ongoing operation involved.

I haven't used dbt State yet either. Its approach brought back memories of solving related problems on client projects, and I'd want to see how much of that work it removes in practice.

These are useful questions precisely because the strategy is becoming broader. The benefit has to show up in the work of building and maintaining a platform.

Business context makes the ambition harder to deliver

The context layer is the announcement I'm most curious about.

In its Context Layer announcement, Fivetran describes the service this way:

Fivetran Context Layer is a managed service that jumpstarts the development of your governed context layer. Build and maintain it directly in your own data warehouse, or in Fivetran Managed Data Lake Service, and serve the right context to any agent that needs it.

Fivetran describes discovering concepts across metadata, wikis, and connected applications and drafting them into an ontology.

That touches a difficult part of client work: getting stakeholders to agree on what their business language means. An agent needs that meaning when interpreting a question, choosing data, and explaining an answer.

Consider a hypothetical business with two paying customer accounts and six individual users. Four users were active this month, spread across both accounts. “Active customers” could mean two accounts or four people, depending on how the person asking uses the word customer.

The agent needs the definitions, the relationships, and enough context to recognize when it should clarify the question. Discovering existing definitions could save substantial work, but it might also reveal disagreements. Those still need to be resolved, or preserved as distinct meanings that the agent can explain.

This is where I see both the appeal and the difficulty of the combined company's position. Working across data movement, transformation, and semantics could help it connect technical metadata with business meaning. I'd want to see how the context layer handles conflicting definitions, who can correct them, and how those corrections reach the agents using it. Those are evaluation questions, not capabilities I've tested.

There's another tension in the messaging that intrigues me. They're emphasizing context engineering as an increasingly important part of our work, while proposing a service that automates the discovery and assembly of that context. So how much of the work do they expect practitioners to do, and how much do they expect the engine to take over?

Their announcement describes the generated ontology as a draft, which suggests a starting point for people to review and refine. That could fit well with a larger role for context engineering. But I'd like to understand where they draw the line: what gets inferred automatically, what requires an explicit business decision, and who's responsible for keeping the two aligned?

What I'll be watching next

Looking back through dbt's releases helped me see a progression in the responsibilities it takes on. The latest announcements extend that progression into more decisions about execution, consumption, and interpretation of data.

My take is that dbt and Fivetran are positioning themselves to be a much more central part of the data platform, with business context for agents becoming an important reason to bring those pieces together. The release history helps explain why they have a credible place to start. The quality of the connections between their products will help determine how useful that position becomes for practitioners.

That's what I'll be watching: whether a metric can keep its definition as it moves from a model to a chart to an agent's answer, and whether a team can inspect and correct the context behind that answer.

If you're evaluating the new offerings, try following one familiar business metric through them. See where its definition is preserved, where you have to repeat it, and where the system needs more context from you. And if you'd like to explore the releases behind this progression, the dbt history app starts at the beginning.