What we Brought Home From dbt Summit 2026: The Announcements Fit Together

One dbt Again, and Open Where it Counts

Until now, teams had to choose between two versions of dbt: the original one and Fusion, a much faster rewrite. dbt v2 ends that choice. There's now one engine for all of dbt, whether you work on your laptop or in the dbt platform, and it's generally available (GA). If you're not ready to move, the previous version stays available as dbt v1, still open source.

Open source is usually the first thing clients ask about, so here's the short answer. dbt v2 comes in two distributions: dbt, which is free and has some optional paid features, and dbt OSS, which keeps only the fully open-source parts. If your company requires fully open-source software, dbt OSS is the one to pick. In our view, that's a sensible split: nobody has to stay on an old engine because of a licensing rule.

Before planning an upgrade, check that your data platform is supported. BigQuery, Databricks, Redshift, and Snowflake already are, and Fabric and Postgres are coming soon.

dbt v2 also brings smaller improvements to daily work, like a built-in code checker and tests that run faster and cost less. Both shorten the time between making a change and knowing it works.

A faster engine is half the story. The other half is deciding what it should run, and where.

Build Only What Changed, and Choose Where it Runs

dbt State is now GA. It checks your warehouse metadata and model SQL for what's changed, then builds, skips, clones, or defers each model accordingly, with an average reduction in warehouse compute of 15–30% or more. It runs on dbt v1.7 through v2, on Snowflake, BigQuery, Databricks, and Redshift.

What caught our attention is less the savings than the change in who decides. With dbt State, every model carries its own `lag_tolerance`, a setting that says how stale it's allowed to be. Freshness moves from the job to the model. In our reading, that means a model that only needs to be updated daily stops being rebuilt every hour just because it sits in an hourly job. As dbt puts it, the guardrails sit in the infrastructure instead of with whoever, or whichever agent, issues the command.

The second cost lever is newer. Lake Compute, in private beta, is a single-node SQL engine built on DuckDB that runs dbt transformations directly against Apache Iceberg tables. You tag one model or a hundred to run there; the rest keep running on your warehouse, and refs keep working across both. The docs example shows how small the change is:

```sql

-- models/model_a.sql: runs on Snowflake, writes an Iceberg table

{{ config(table_format='iceberg', materialized='table') }}

select 1 as id

-- models/model_b.sql: runs on Lake Compute

{{ config(adapter='lakecompute') }}

select * from {{ ref('model_a') }}

```

The full example needs an experimental multi-adapter setting. During the beta, Lake Compute supports only Snowflake, in two AWS regions, and it's meant for workloads that don't need a distributed warehouse's full scale.

For us, the bigger shift is reading from a lake you own. Fivetran's Managed Data Lake Service, already GA, maintains data as Iceberg tables in the customer's own cloud storage. It's the change we expect to matter most over time. Choosing an engine used to mean a replatforming project; now it can be a config line on one model.

Cheaper runs matter, but most of the Summit's energy went to what happens when an agent does the work.

An Agent That Knows the Project, and Dashboards That Live Next to it

dbt Wizard is an AI agent built for data development in dbt. Unlike general-purpose coding agents, it understands your project through a structured index of lineage, model health, tests, contracts, run results, and semantic definitions. Before anyone sees a change, it compiles and builds it, then checks the upstream and downstream impact. It's in public preview in the dbt platform, in public beta as a CLI, and in private beta as a desktop app.

Teams can bring their own model key, and usage is metered per token from September 1, 2026. You can also give it skills: reusable instructions for your project.

For business users, Explore Mode answers plain-language questions grounded in the same dbt project, and when an answer falls short, you're one step from the model that needs fixing. Read-only users don't need a developer license, though usage is still billed.

All of this depends on context, something we've covered in our post on semantic models for AI agents. The dbt MCP Server now has out-of-the-box integrations with Anthropic and a plugin for ChatGPT, both GA. Agents Schema, an open-source standard, designates one schema in the warehouse as the shared context layer for agents, stored as plain SQL tables.

dbt Charts, in public beta, defines dashboards as YAML that's version-controlled right next to the models they depend on: same repo, same pull request, same CI. The language is open source under Apache 2.0, with an optional hosted platform at dbtCharts.com. In practice, a change to a model and to the dashboard built on it can go through the same review. We’ve gone deeper in our full review of dbt Charts.

That's what dbt announced. The conversations with other attendees showed us where teams are still working things out.

If you’re running dbt in production, we can look at your project and estimate what dbt State would save you in warehouse compute. Happy to walk you through it.

Frequently Asked Questions

Is dbt still open source? Yes, with a nuance. dbt v1 (formerly dbt Core) and dbt OSS are Apache 2.0. The full dbt distribution is free to use but isn't 100% Apache.

What does dbt State do? It checks your model SQL and warehouse metadata for changes, then skips, clones, defers, or rebuilds each model accordingly. dbt reports an average reduction in warehouse compute of 15–30% or more.

Can I use Lake Compute today? It's in private beta. During the beta, Snowflake is the only supported warehouse, it runs in AWS us-east-1 and us-west-2, and you need a dbt project on v2.