dbt Fusion and dbt 2.0: What Changed and What Your Team Should Do

dbt 2.0 is the first major version of dbt since v1.0 shipped in 2021. Released in alpha on June 1, 2026, it rebuilds dbt Core on the same Rust engine that powers the dbt Fusion engine, ends the two-engine era, and keeps the open-source code under the Apache 2.0 license. Fusion is the enhanced distribution of that same engine. It adds SQL comprehension, column-level lineage, and premium features that unlock with a free login or a paid dbt platform account. 

The engineering deserves the attention it's getting. This guide covers the release, the strategy shift underneath it, and a clear framework for deciding what your team should do. 

What Is dbt 2.0? 

dbt 2.0 is a ground-up rewrite of the dbt engine in Rust. It replaces the Python runtime that powered every dbt version since the project began. 

The performance case is straightforward. Parse times drop significantly on large projects. A tightly defined language spec catches configuration typos that the old parser silently ignored. New Parquet artifacts replace large JSON files and can be queried directly with DuckDB or an AI agent. Alongside the release, dbt Labs shipped dbt Docs v2, a faster catalog experience, and dbt lint, a SQLFluff-compatible linter. dbt Labs benchmarks it at roughly 50x faster than single-threaded SQLFluff, though most teams run SQLFluff with multiple processes in CI, and SQLFluff 4.0 now ships its own optional Rust-backed parser. The whole SQL tooling chain is moving to Rust, and the practical speed gap will keep narrowing. 

The release landed the same day the Fivetran and dbt Labs merger officially closed. That timing matters, and we cover it below. 

What Is the dbt Fusion Engine? 

The dbt Fusion engine is dbt Labs' next-generation runtime, first launched as a public beta on May 28, 2025 under the Elastic License v2. It has native SQL understanding across warehouse dialects, which enables features the Python engine never could: static analysis that catches SQL errors before they hit the warehouse, column-level lineage, and a language server that powers the dbt VS Code extension. 

With dbt 2.0, the picture simplified. The runtime code that lived in the dbt-fusion repo under ELv2 moved into the dbt-core repo under Apache 2.0. Fusion is now the precompiled, enhanced binary built on that open foundation. The dbt-fusion repo is archived, and dbt-core is the single home for issues and contributions. 

Soundbite: dbt 2.0 collapsed two engines into one Rust foundation. The split moved from the codebase to the license. 

dbt Core v2 vs Fusion: What's the Difference? 

dbt Core v2 and Fusion run the same language, the same DAG semantics, and the same runtime. Everything that separates them shows up in licensing, cost, and developer tooling. 

The last row is the honest way to read this release. Fusion is genuinely free and the license now lets any vendor, Datacoves included, offer it as a managed service, as long as the path to a dbt Labs account stays open. That's the point. Fusion is distribution for the paid dbt platform, the way a free tier exists to create upgrades. There's nothing wrong with the model, and the developer experience is real. Just evaluate it as what it is: an engine whose economics depend on some share of its users becoming dbt Labs customers. 

Is dbt Still Open Source? 

Yes, with an asterisk. The dbt framework, language, and Rust runtime are Apache 2.0 open source in the dbt-core repository. That's more open than a year ago, when the Rust code sat under ELv2. 

The asterisk is the recommended path. Fusion carries proprietary code on top of the open core, and the new dbt login command connects the CLI to a dbt platform account: a free login unlocks advanced features, a paid license unlocks premium ones. None of this is hidden, and dbt Labs deserves credit for open-sourcing code it could have kept closed. Every team should just be clear that the distribution dbt Labs recommends is the commercial one, and the fully open one now requires choosing it deliberately. 

Community sentiment reflects this tension. Reaction to the release mixed genuine enthusiasm for the performance gains with skepticism about the Fivetran merger, the freemium hooks, and dbt Core's long-term priority. dbt Labs has responded by hiring more Core developers and relicensing code, which is encouraging. Watch what ships over the next year. 

We covered the merger's implications for dbt Core in depth in dbt Core's Future in the dbt Fivetran Era. Since that article, Fivetran donated SQLMesh, the transformation framework it acquired with Tobiko Data, to the Linux Foundation for community governance. That gives teams a fully open-source alternative to dbt with neutral stewardship, and it signals that Fivetran intends to compete on openness. Datacoves customers can run SQLMesh on the platform today, the same way they run dbt Core, so evaluating it doesn't require a platform change. 

What Fusion Costs 

Fusion itself is free to install and run, including in production. The costs show up in the features around it: 

• Free, no account: the engine, parsing, compilation, runs, and the built-in SQL linter
• Free login required: advanced dbt VS Code extension features
• Paid: dbt platform features, and now dbt State at $0.094 per daily unique reuse, with a 30-day trial 

dbt State deserves attention. It skips or clones models when logic and data haven't changed, which can cut warehouse spend. It's also a first for dbt. Until now, usage-based pricing lived in the hosted platform. dbt State puts a meter inside the engine workflow itself, billed per model reused per day. Evaluate it the way you'd evaluate any metered service: model the cost at your project's size today, then at the size you expect in three years, and decide whether the warehouse savings still clear the bill. 

 The market responded fast. Within weeks of dbt State pricing going live, Orchestra open-sourced Sao Paolo, its state-aware orchestration for dbt Core, under Apache 2.0. It skips models and their downstream dependencies when source freshness checks show no new data and no code has changed, works with the Python dbt Core you run today, and doesn't require Orchestra's platform. Both products are new to market this year. dbt State inherits its detection logic from dbt's earlier state-aware orchestration, so it's the more refined of the two, while Sao Paolo trades some sophistication for a free license and no engine upgrade. Either way, its existence changes the negotiation. Metered pricing on state now competes with free. 

Four Ways to Manage dbt State 

State management answers one question: how does dbt know what actually needs to rebuild? There are now five ways to answer it, all of which work with the dbt project you have. 

Two things stand out in that table. Every option except dbt State is free, which puts the burden on dbt Labs to prove the metered version earns its cost through better change detection. And none of them require leaving dbt. The decision is about where state lives: an artifact, a shared service, an open-source package, the warehouse, or the orchestrator. Your transformation framework stays the same on every path. 

For most teams already running dbt Core, the practical sequence is: get Slim CI and deferral working first, since they're free and cover most of the waste, then evaluate Sao Paolo or dbt State only if redundant rebuilds still show up as real warehouse spend. 

What Breaks When You Upgrade 

v2 removes all deprecated functionality, and every deprecation warning must be resolved before the new engine will run your project. Beyond that, plan for these: 

1. Python models. Fusion can't parse them yet. Projects that depend on Python models can't fully migrate.
2. Custom and community adapters. Fusion's new adapter pattern requires drivers signed by dbt Labs. Snowflake, Databricks, BigQuery, and Redshift are covered; niche adapters are not.
3. Packages. Major dbt Labs packages like dbt_utils are Fusion-compatible. External packages may fail to parse until maintainers update them.
4. CLI flags. --models and -m now error. --partial-parse is gone. Job definitions and scripts need review.
5. Installation model. The Rust binary replaces the pip-and-virtualenv pattern. Teams managing many environments will want containerization to carry that load.
6. Behavior changes. Threading, compile error handling, and unit test ordering all work differently. Test before you trust.

How to Test Fusion Readiness 

The check takes an afternoon: 

1. Upgrade to dbt Core v1.12 and clear every deprecation warning.
2. Run dbt parse --use-v2-parser. This delegates parsing to the new engine without changing behavior.
3. Run dbt-autofix to handle mechanical fixes for packages and deprecations.
4. Inventory blockers: Python models, custom adapters, unsupported materializations.
5. Trial Fusion in a development environment side by side with Core. Manifests are compatible enough to migrate incrementally.

Should You Migrate Now? 

Here's the call: 

• Adopt Fusion now if you're on Snowflake, Databricks, BigQuery, or Redshift, your project parses clean under the v2 parser, and the developer experience gains (lineage, static analysis, speed) outweigh dependence on a freemium roadmap.
• Standardize on dbt Core v2 if you're in a regulated industry, have procurement or licensing requirements around open source, or build tooling on the framework. You get the same Rust performance with none of the commercial hooks. It's in alpha, so target GA for production.
• Wait on v1.12 if you depend on Python models, community adapters, or packages that haven't been updated. v1.12 is stable, supported, and ships the v2 parser flag so you can prepare without committing.

Whatever you choose, resolve your deprecations now. That work pays off on every path. 

Own the Platform, Whatever the Engine Does 

Datacoves has run managed dbt Core in customers' private clouds since before Fusion existed, orchestrated with Airflow, versioned in Git, gated by CI/CD the customer owns. Fusion is the dealership's tuned edition of the engine. Core v2 is the one you can rebuild in your own garage. Both will move you down the road, but only one of them never asks you to log in. 

The dbt engine consolidating onto one foundation is good for everyone. It doesn't change the evaluation that matters for a data leader: who controls your development environment, your orchestration, your CI/CD, and your exit. Teams that anchor on open-source dbt, independent orchestration, and a platform deployed in their own cloud can adopt Fusion's improvements on their own schedule, and walk away from any pricing change that doesn't serve them. 

If you're planning a dbt 2.0 migration and want a second set of eyes on your platform architecture, book a free architecture review.