One dbt, Smarter Pipelines, AI-Ready Context: Our Takeaways from dbt Summit 2026

Matěj Novák, Senior Data Engineer at Revolt BI, is attending dbt Summit for the second year in a row. This is his firsthand perspective on what’s GA, what’s still to watch, and what your data team should actually do about it.

Being at dbt Summit in person this year (big thanks to Revolt BI and Joyful Craftsmen for making that possible) felt different from the previous year, at least in my opinion. Last summit brought a wave of announcements that were mostly coming soon at the time. This time, a lot of what got announced back then has actually reached GA, so this recap covers things teams can put into production right now.

one dbt again

Tristan Handy opened with the news the dbt community had been waiting for: dbt Core and dbt Fusion are merged into one dbt, now called dbt v2. One engine, one language spec, no more choosing between “the stable one” and “the fast one.” It’s GA, still open source under Apache 2.0, and it ships as two distributions: a superset dbt that includes the SQL comprehension features (some paid, like dbt State), and a fully open dbt-oss subset for teams who want to stay strictly Apache 2.0. I don’t have concerns about the licensing direction itself, the open core plus paid extensions model makes sense and can genuinely add value. Where it’s worth watching is dbt State pricing specifically, though it’s still too early to draw conclusions there.

The performance numbers are the part that will actually change how teams work day to day. Timothy Leonard from Spotify shared that their compile time dropped from 90+ seconds to around 10, and across all their pipelines that adds up to tens of thousands of compute hours saved on compile time alone. That’s not a nice-to-have, that’s hours of engineer time given back every single day.

Migration is handled by tooling built specifically for this transition, and dbt made a clear effort to keep it smooth: an incremental path rather than a hard cutover, so teams can move at their own pace instead of a forced switch. I tried dbt-autofix myself on one of our projects, and it was smooth and simple.

What dbt v2 actually brings

Beyond the merge itself, v2 is packed with changes that quietly remove friction across the whole workflow. A new Rust parser makes parsing and compiling noticeably faster, especially on large projects. Strict validation now catches misspelled config keys, deprecated properties, and wrong data types immediately instead of letting them slip through. New adapters are built on ADBC drivers, which means easier installs and faster connectivity, and GA now covers BigQuery, Databricks, DuckDB, Redshift, and Snowflake, with ClickHouse and Spark in beta and Athena, Fabric, and Postgres coming soon.

Testing gets smarter too. The –batch-tests flag groups multiple tests on a model into a single query instead of firing one query per test, and the internal numbers are striking: 40 percent shorter test runtime, 65 percent fewer queries, 15 percent lower warehouse cost. One demo project went from 156 queries down to 21.

Project metadata is now exposed through a proper contracted interface, the dbt Information Schema, stored as Parquet instead of the old JSON artifacts, and queryable with dbt show –info, including column-level lineage. dbt-docs got a full rebuild on DuckDB WASM, scales to large projects, and still ships as a static, easy-to-host site.

For day-to-day development, dbt lint runs the SQLFluff rules you already know but natively and dramatically faster, and a Language Server Protocol gives editors and coding agents live autocomplete, navigation, and inline diagnostics. Packages can now ship skills that teach agents their specific quirks, installed automatically during dbt deps.

None of these is a single headline feature on its own. Taken together, though, they’re the difference between waiting on your tooling and just working.

dbt State: the guardrail moves into the infrastructure

This is the one I keep coming back to. dbt State is now GA and checks your warehouse metadata and model SQL for what’s actually changed, then decides whether to build, skip, clone, or defer each model accordingly. dbt Labs is citing an average 15 to 30 percent reduction in warehouse compute, and it works across dbt v1 through v2, wherever you run it, locally, on the platform, or with your own orchestrator. Worth noting how it works under the hood too: dbt only stores metadata and a hash of the query, never the actual data or the query text itself, and because the queries are standardized first, a stray whitespace or an added comment won’t change the hash and won’t trigger an unnecessary rebuild.

What I find genuinely important here isn’t the cost saving, it’s where the guardrail sits. Freshness now lives on the model itself, as a lag_tolerance in code, instead of being enforced by whoever (or whichever agent) happens to trigger a run. That’s exactly the kind of foundation you want before you start letting agents run dbt commands on your behalf: the safety net isn’t a convention anyone can forget, it’s built into the platform.

Lake Compute: engine choice as a per-model decision

Elias DeFaria introduced Lake Compute, now in private beta, and it’s the first concrete piece of dbt and Fivetran’s bigger “open data infrastructure” pitch, building an end-to-end platform out of open components like Lego bricks. Lake Compute is a single-node SQL engine built on DuckDB that runs directly against Apache Iceberg tables. You tag individual models to run there instead of your warehouse, the rest of the project keeps running as normal, and refs keep working across both. Engine choice becomes something you decide per model, not a replatforming project. I like this direction a lot, but it’s still private beta, so this is one to watch rather than adopt tomorrow.

On the Fivetran and dbt Labs merger itself, from where I sit as a partner, it doesn’t feel like a fundamental shift. dbt is still clearly committed to staying open source. What changed is more additive, Context Layer being the clearest example, which lives inside Fivetran as its own isolated service. Nobody’s being pushed to migrate onto anything.

Context for AI agents, not just more data

Tyler Pugliese‘s talk was the one that made me think the most, and honestly, alongside open data infrastructure, context for AI was the other main theme running through almost every talk at this summit. The pitch is that AI agents don’t need more of your data, they need to actually understand what it means, where it came from, how fresh it is, and who owns it. dbt Labs is leaning on the Semantic Layer and Agents Schema for that, plus dbt now has out-of-the-box integrations with Anthropic and a ChatGPT plugin, so instead of managing multiple MCP servers, structured project context is one click away.

On the ingestion side, Fivetran Context Layer takes this further: connectors now carry metadata about the sources and their elements as data moves, and it also covers unstructured sources, call recordings, support tickets, Slack threads, not just tables. That’s a much bigger claim than structured metadata, and it’s currently private beta / early access.

Developer experience: dbt Wizard and dbt Charts

Samantha Ferguson closed the keynote with the tools people will actually touch day to day. dbt Wizard, the coding agent grounded natively in your project, is now in public preview. If you already have an OpenAI subscription or an Anthropic API key, you can start using it right away, alongside Wizard Explore Mode for conversational analytics inside the dbt platform, a Wizard CLI for people who never want to leave the terminal, and Wizard Desktop, a private beta local workspace for running several agentic tasks side by side.

dbt Charts is the one closing a gap: dashboards defined as YAML, version-controlled next to the models they depend on, living in the same repo and the same pull request as the SQL underneath. It’s still public beta, but it’s the first time dashboards get the same engineering discipline dbt already gave SQL.

From a consultant’s point of view, both feel like the kind of thing worth keeping an eye on rather than rolling out to clients on day one. I haven’t had a good opportunity yet to properly test Wizard with a client project. Charts is a fairly specific use case and quite new, so it’s not something I’d put at the center of a client implementation from the start, maybe on a smaller piece of work once it’s had more time to mature.

Where I think this actually goes

My honest takeaway from this summit, more than any single feature, is that the gap between “interesting idea” and “thing I can implement next quarter” got a lot smaller compared to last year. dbt State alone is something every team should at least check out, there’s a 30 day trial available, so there’s no reason not to see whether it’s worth it for you. The semantic layer and context engineering direction is the one I’m most excited about: conversational analytics and streaming analytics both depend on exactly this kind of trustworthy, well-modeled context, and dbt is clearly betting its whole product line on that being the foundation.