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

dbt 2.0 is the first major version of dbt since v1.0 shipped in 2021. It rebuilds dbt on the Rust engine behind dbt Fusion, which ends the split between a Python dbt Core and a separate Rust engine. dbt 2.0.0 shipped on September 14, 2026, after a June 1 alpha, and dbt Labs announced general availability two days later. It comes in two free distributions:

• dbt is the proprietary build powered by the Fusion engine, and it’s now the default install.
• dbt-oss is the fully open-source build under Apache 2.0.

You don’t have to move to dbt Cloud to get Fusion. Datacoves runs dbt Fusion today in the same managed VS Code workspace your engineers already use. The official dbt VS Code extension is supported, and everything runs in your own cloud.

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 release since the project began. It’s the version of dbt you get by default when you install dbt today.

The performance case is straightforward:

• Faster parsing. Parse and compile times drop sharply on large projects.
• Stricter configuration checks. A tightly defined language spec catches configuration typos the old parser silently ignored.
• Queryable artifacts. New Parquet artifacts replace bloated JSON files. You can query them directly with DuckDB or hand them to an AI agent.
• dbt Docs v2. A faster, statically hostable catalog.
• A DuckDB adapter. v2 adapters connect through ADBC drivers, and DuckDB is one of the warehouses the v2 CLI supports. That matters for teams running a lean DuckDB and DuckLake stack.

The release also introduced dbt lint, a SQLFluff-compatible linter. dbt Labs benchmarks it at roughly 50x faster than single-threaded SQLFluff. Most teams already run SQLFluff in parallel in CI, though, and SQLFluff 4.0 ships its own optional Rust-backed parser. The whole SQL tooling chain is moving to Rust, so the practical speed gap will keep shrinking.

The timeline in brief:

• May 28, 2025: Fusion launched in public beta.
• June 1, 2026: dbt Core v2 alpha shipped, the same day the Fivetran and dbt Labs merger closed.
• September 14, 2026: dbt 2.0.0 shipped on PyPI, with the CLI rebranded to dbt and dbt-oss. Patch releases have followed steadily since.
• September 16, 2026: dbt Labs announced general availability at dbt Summit.

Source: dbt v2.0.0 release notes.

What Is dbt Fusion?

dbt Fusion is dbt Labs’ Rust-based engine and the proprietary distribution of dbt 2.0. It understands SQL natively across warehouse dialects. Since September 2026, “Fusion” mostly names the engine, and the package you install is simply called dbt.

Native SQL comprehension unlocks things the Python engine never could:

• Static analysis that catches invalid columns and type mismatches before a query reaches the warehouse.
• Column-level lineage.
• A language server that powers the official dbt VS Code extension, with autocomplete, hover info, and inline errors.

The licensing path matters here. Fusion launched under the Elastic License v2. With dbt 2.0, dbt Labs moved that runtime code into the dbt-core repository under Apache 2.0 and archived the dbt-fusion repo. Fusion is now the precompiled, enhanced binary built on top of that open foundation.

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

dbt Fusion vs dbt Core: What’s the Difference?

dbt Fusion and dbt Core v2 run the same language, the same DAG semantics, and the same runtime. What separates them is licensing, cost, and developer tooling. Python dbt Core v1.12 is a different engine entirely, and it’s still the stable choice for projects that aren’t ready for v2.

Fusion is genuinely free, and its license lets any vendor offer it as a managed service, Datacoves included. The premium tiers sit above the free engine, which is a normal and well-understood way to fund this kind of work.

What it means for you is practical. Decide which capabilities you actually need from the paid tiers, and price those, rather than assuming the free engine and the paid platform are one purchase.

Is dbt Still Open Source?

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

The asterisk is the default path. Running pip install dbt now gives you the proprietary Fusion distribution. Its dbt login command connects the CLI to a dbt platform account, where a free login unlocks advanced features and a paid plan unlocks premium ones. None of this is hidden, and dbt Labs deserves credit for open-sourcing code it could have kept closed. The practical consequence for your team is that the fully open distribution is now something you choose deliberately.

Community sentiment reflects that tension. Reaction to dbt 2.0 mixed real enthusiasm for the performance gains with skepticism about the Fivetran merger, the freemium hooks, and dbt Core’s long-term priority. dbt Labs has hired more Core developers and relicensed code, which is encouraging. Watch what ships over the next year.

We covered the merger in depth in dbt Core’s Future in the dbt Fivetran Era. Since then, Fivetran donated SQLMesh to the Linux Foundation for community governance. That gives teams a fully open-source dbt alternative with neutral stewardship. Datacoves customers can run SQLMesh on the platform today, so evaluating it doesn’t require a platform change. For the wider field, see dbt Alternatives: 10 Platforms Compared.

How Much Does dbt Fusion Cost?

dbt Fusion is free to install and run, including in production. The costs show up in the premium features:

• Free, no account: the engine, parsing, compilation, runs, and dbt lint.
• Free login required: advanced features in the dbt VS Code extension.
• Paid: dbt platform features, plus dbt State at $0.094 per daily active target table (DATT), after a 30-day trial.

dbt State deserves a closer look. It skips or clones models and tests when logic and data haven’t changed, which can cut warehouse spend. It also puts a meter inside the engine workflow for the first time. Until now, usage-based pricing lived only in the hosted platform.

Here’s how the billing unit works. Every model, snapshot, seed, and test that dbt State reuses counts as a target table. A model with two tests is three target tables. Each one is billed once per day it gets reused. A paid platform plan isn’t required, but a dbt account is.

Model the cost the way you’d model any metered service:

• Estimate the cost at your project’s size today, tests included.
• Estimate it again at the size you expect in three years.
• Decide whether the warehouse savings still clear the bill.

Seat pricing is the other half of the math. dbt Cloud’s Starter plan runs $100 per developer per month and caps at five seats. Enterprise is quote-only. Our full breakdown is in dbt Pricing: Is dbt Free? dbt Cloud Costs Explained.

The market responded fast. Within weeks of dbt State pricing going live, Orchestra open-sourced Sao Paolo under Apache 2.0. It’s state-aware orchestration for Python dbt Core. Sao Paolo skips models and their downstream dependencies when source freshness checks show no new data and no code has changed, and it doesn’t require Orchestra’s platform. dbt State inherits more refined change detection from dbt’s earlier state-aware orchestration. Sao Paolo trades some of that sophistication for a free license and no engine upgrade. Metered state now competes with free.

dbt Fusion is free to run. The meter starts when dbt State reuses a model, and it counts every test too.

Do You Need dbt Cloud to Use dbt Fusion?

No. Fusion is a free binary, and you can run it anywhere the license allows, including managed platforms other than dbt Cloud.

That point gets lost because dbt Cloud bundles the engine with everything around it: the Studio IDE, the job scheduler, per-seat pricing, and metered add-ons. Teams that want Fusion’s speed and SQL comprehension can take the engine on its own and price the platform around it separately.

Datacoves runs dbt 2.0 (Fusion) today. Your engineers get Fusion in the same managed, in-browser VS Code workspace they already use, and the official dbt VS Code extension is supported. Nobody rebuilds an environment, and nobody learns a new IDE.

Projects that aren’t ready can stay on dbt Core v1.12 on the same platform while others move to Fusion. Production keeps running on managed Airflow and the CI/CD you already own.

Fusion’s premium features still come from dbt Labs, wherever you run the engine. A free login unlocks the advanced extension features, and dbt State bills through a dbt account. Datacoves doesn’t change that. What changes is everything else: where the platform runs, what you pay per developer, and how easily you can leave.

If you’re weighing the broader platform decision, our dbt Core vs dbt Cloud guide covers it in detail, and Datacoves vs dbt Cloud gives the head-to-head.

You can run dbt 2.0 (Fusion) without dbt Cloud. Datacoves gives teams dbt and the official dbt VS Code extension in their own cloud.

Four Ways to Manage dbt State

State management answers one question: how does dbt know what actually needs to rebuild? There are now four answers, and every one of them works with the dbt project you already have.

Two things stand out. Every option except dbt State is free, so the burden is on dbt Labs to prove better change detection earns the meter. And none of them require leaving dbt. The real decision is where state lives: an artifact, a shared service, an open-source package, or the warehouse.

For most teams, the right sequence is simple. Get Slim CI and deferral working first, since they’re free and cover most of the waste. Evaluate Sao Paolo or dbt State only if redundant rebuilds still show up as real warehouse spend.

What Breaks When You Upgrade to dbt 2.0

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

1. Python models. dbt v2 supports them on Snowflake, BigQuery, and Databricks. Validate yours in a development environment before you move production workloads.
2. Custom and community adapters. v2 adapters live in dbt Labs’ Rust monorepo and connect through ADBC drivers. Snowflake, Databricks, BigQuery, Redshift, and DuckDB are covered. Niche community adapters may not be.
3. Packages. Major dbt Labs packages like dbt_utils are Fusion-compatible. External packages may fail to parse until maintainers update them. Check the Fusion-compatible badge on the dbt package hub.
4. CLI flags. --models and -m now raise errors, so use --select or -s. dbt 2.0 (dbt Fusion) job runs no longer support --partial-parse. Review job definitions and scripts.
5. Installation model. A compiled binary replaces the Python dependency tree. Teams managing many environments will want containerization, or a platform that handles it for them.
6. Behavior changes. Threading, compile error handling, and unit test ordering all work differently. Test before you trust.

Full details are in dbt Labs’ upgrade guide for v2.

How to Test dbt 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 hands parsing to the new engine without changing runtime behavior.
3. Run dbt-autofix to handle mechanical fixes for packages and deprecations.
4. Inventory blockers: custom adapters, custom materializations, and adapter-specific materializations not yet ported to your warehouse.
5. Trial Fusion in a development environment side by side with Core. Manifests are compatible enough to migrate incrementally.

On Datacoves, step 5 happens in the workspace your team already uses. You don’t need a separate sandbox, and you don’t need a dbt Cloud trial.

Should You Migrate to dbt Fusion Now?

Here’s the call:

• Adopt Fusion now if you’re on Snowflake, Databricks, BigQuery, Redshift, or DuckDB, and your project parses clean under the v2 parser. Do it when the gains in lineage, static analysis, and speed outweigh your dependence on a freemium roadmap. Run it on a platform you control so the engine choice stays reversible.
• Standardize on dbt-oss if you’re in a regulated industry, have procurement rules around open source, or build tooling on the framework. You get the same Rust performance with none of the commercial hooks. dbt Labs points new installs at the dbt distribution, so pilot dbt-oss on a real project before you move production onto it.
• Stay on v1.12 if you depend on community adapters, packages that haven’t been updated, or materializations v2 hasn’t ported to your warehouse. v1.12 has active support through July 15, 2027, 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 in customers’ private clouds since before Fusion existed. It’s orchestrated with Airflow, versioned in Git, and gated by CI/CD the customer owns. Today that includes dbt v2 (aka dbt Fusion) and the official dbt VS Code extension, alongside dbt Core.

dbt Fusion is the dealership’s tuned edition of the engine. dbt-oss is the one you can rebuild in your own garage. Both will get you down the road, and only one of them never asks you to log in. Where you park either one is a separate decision, and it’s the one that determines your exit costs.

The 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 today and still change course later.

If you’re weighing dbt v2 and want a second set of eyes on the architecture around it, book a free architecture review. We’ll look at your v2 readiness and how your platform would run in your own cloud.