Two Engines, One Project
Four things, not two. dbt Core v1.x is the Python implementation — Apache 2.0, stable, what you run today. dbt Core v2.0 is the Rust RUNTIME, relicensed out of Fusion under Apache 2.0, and it is an alpha. The dbt Fusion engine is a free binary containing that runtime plus, in dbt Labs' words, "some proprietary code" — free to use, still proprietary, licensed under its own agreement. dbt platform is the commercial SaaS, formerly dbt Cloud. Licence, implementation, distribution and hosting are four separate axes, and every confusing sentence about Fusion is two of them collapsed into one.
Twenty-one chapters have targeted one thing: dbt Core 1.12.0, the Python implementation, current stable since 16 July 2026. That is still the right target. But the names around it moved twice in fourteen months, and the version of this story most engineers are carrying — "Core is the Python one, Fusion is the proprietary Rust one" — stopped being true on 1 June 2026.
The widget below runs the same faults through three engines. Ignore speed. The question that decides a migration is how much of your project each engine understands before it sends anything to a warehouse.
Four things, not two. dbt Core v1.x is the Python implementation — Apache 2.0, stable, what you run today. dbt Core v2.0 is the Rust RUNTIME, relicensed out of Fusion under Apache 2.0, and it is an alpha. The dbt Fusion engine is a free binary containing that runtime plus, in dbt Labs' words, "some proprietary code" — free to use, still proprietary, licensed under its own agreement. dbt platform is the commercial SaaS, formerly dbt Cloud. Licence, implementation, distribution and hosting are four separate axes, and every confusing sentence about Fusion is two of them collapsed into one.
Getting these four names wrong costs real money in two directions. Teams migrate to "the open-source Rust engine" and discover the binary they installed is proprietary and the Apache-licensed runtime is an alpha with no beta and no RC behind it. Other teams refuse to look at Fusion because "it is closed", and give up a static-analysis capability that catches a class of defect — an unresolvable column — that dbt Core 1.x structurally cannot see, since it templates SQL rather than comprehending it. The second cost is quieter: on dbt Core 1.x there is no column-level lineage at all, which Chapter 11 established, so every impact question is answered by reading models rather than by asking the tool.
- dbt Core 2.0, precisely
- The Rust runtime, open-sourced out of Fusion and released as dbt Core under Apache 2.0 on 2026-06-01. Current build 2.0.0a5 (git tag v2.0.0-alpha.5), 20 July 2026. There is no beta, no release candidate and no GA — anyone who tells you dbt Core 2.0 is stable has not read the tag.
- The dbt Fusion engine
- A free binary distribution built on the v2 runtime plus proprietary code, licensed under the agreement published at getdbt.com/dbt-fusion-engine-license-agreement — that is the page title; the document itself opens by naming itself the "dbt Product Licensing Agreement." Not deprecated: the docs (updated 2026-07-31) describe it as the default experience when you install dbt. Free to use is not the same as open source, and both halves of that sentence are load-bearing.
- static_analysis
- A Fusion-only config, ignored by dbt Core, taking strict | baseline (default) | off. It is settable in dbt_project.yml (+static_analysis:), in a model's YAML config:, or via {{ config(static_analysis='off') }}, with a --static-analysis CLI flag. Setting it off costs syntax and type checking, CTE previews, and column-level lineage — and it PROPAGATES: a child can never be stricter than its parent.
- v2 adapters are re-implemented, not recompiled
- The v2 adapters are written in Rust inside the dbt-core monorepo and connect through a pre-existing ADBC driver — dbt Labs do not write drivers. The extension point is an AdapterType enum plus match adapter_type() arms across roughly thirteen files. Your existing Python dbt-<adapter> package does not work on v2; only the Jinja macro layer ports over. That is why the adapter matrix is short and why it grows slowly.
- Support windows, which are dated — unlike the sunset, which is not
- One year of support per minor: 1.12 is in active support until 2027-07-15, 1.11 is critical-only until 2026-12-18, 1.10 is deprecated. There is no announced end for the 1.x line at all. dbt Labs, verbatim: "You don’t have to move to v2.x today, tomorrow, or ever."
-- models/marts/mart_episode_catalogue.sql
select
episode_id,
episode_titel -- transposed, and upstream has no such column
from {{ ref('int_episode_catalogue') }}| Name | What it is | Licence | Status on 2026-08-04 |
|---|---|---|---|
| dbt Core v1.x | The original Python implementation | Apache 2.0 | Stable — 1.12.0, 16 Jul 2026. What this KB targets. |
| dbt Core v2.0 | The Rust runtime, open-sourced out of Fusion | Apache 2.0 | ALPHA — 2.0.0a5, 20 Jul 2026. No beta, no RC, no GA. |
| dbt Fusion engine | A free binary: the v2 runtime plus some proprietary code | Proprietary — "dbt Fusion Engine License Agreement" (page title); the document itself is the dbt Product Licensing Agreement | Not deprecated. The docs (upd. 2026-07-31) call it the default experience when you install dbt. |
| dbt platform | The commercial SaaS, formerly dbt Cloud (renamed May 2025) | Commercial | GA — Developer (Free) · Starter $100/user/mo · Enterprise · Enterprise+ |
The 'postgres' adapter is not yet supported by dbt Fusion.
Supported adapters: snowflake, bigquery, databricks, redshift| Adapter | Fusion status (docs updated 2026-07-31) | What that means for a team |
|---|---|---|
| Snowflake | GA | The one adapter where "should we adopt it in production" is a real question rather than a bet |
| BigQuery | Preview | Fine in development; a production switch is a decision about your appetite for preview software |
| Databricks | Preview | Same shape as BigQuery |
| Redshift | Preview | Same shape again — and note Cost Insights is only Preview here too |
| Spark | Beta — CLI only | Per-surface, not just per-adapter: the CLI qualifier is the part people drop when they repeat this |
| DuckDB | Beta — CLI only | Same qualifier |
| Postgres | NOT SUPPORTED | The single most common local development setup in the dbt world. This is the row to check first, not last. |
Status is per adapter AND per surface. "Fusion is GA" and "Fusion is preview" are both wrong as unqualified sentences, and one of them is wrong in the expensive direction.
| Surface | Status on 2026-08-04 | The detail that changes what you do |
|---|---|---|
| dbt lint / dbt format | Beta — v2 and Fusion only, built into the dbt platform | SQLFluff-compatible: it reads .sqlfluff, uses the same rule codes (CP01, RF03) and honours -- noqa. On dbt Core 1.12 you are running SQLFluff, not dbt lint — do not send a 1.12 reader to it. No speed figure is printed here: two conflicting vendor numbers exist and no independent one does. |
| dbt Docs v2 | Alpha | Needs Fusion or dbt Core 2.0. dbt compile --write-index, then dbt docs serve. Column-level lineage only on Fusion with --static-analysis strict. |
| dbt State | Preview | Works with dbt Core, Fusion, dbt platform and external orchestrators — Chapter 15 handed it forward with exactly that framing. Config lag_tolerance. Usage-billed, with billing beginning 2026-09-01. |
| Cost Insights | GA on Snowflake, BigQuery and Databricks (Jul 2026); Redshift Preview | The cost attribution Chapter 16 built by hand, as a product — on three adapters. |
| Column-level lineage | Two paths, neither of them free and open | dbt Catalog on dbt platform is GA but Enterprise / Enterprise+ only. dbt Docs v2 on Fusion or Core 2.0 is alpha and needs --static-analysis strict. It is not in dbt Core 1.x at all, which Chapter 11 established and this confirms. |
Reading "the runtime is now Apache 2.0" as "Fusion is open source now". You tell a procurement or legal reviewer something false, and they find out from the licence file. Only a subset — the runtime — was relicensed, and it ships as dbt Core 2.0 in alpha. The Fusion binary you actually install is governed by the dbt Fusion Engine License Agreement and contains proprietary code by dbt Labs’ own description. The correct sentence has both halves in it.
Reaching for static_analysis: off to make a stubborn model migrate. You pay the entire migration and keep none of the benefit. off costs syntax and type checking, CTE previews and column-level lineage — and because a child can never be stricter than its parent, everything downstream of that model loses them too. The worst part is that it looks like success: the build is green, and you believe you have migrated.
Say "dbt platform (formerly dbt Cloud)" the first time in any document that will outlive the week. Half your readers learned the old name; the other half have never seen it.
Before quoting a Fusion status, name the adapter and the surface. "GA on Snowflake; Postgres not supported" is a sentence you can defend. "Fusion is GA" is not.
Put two dates in a calendar rather than a migration in a roadmap: your adapter’s Fusion status, and your minor version’s support window. Those are the only two things that will actually force your hand.
The engine renders your Jinja to DDL exactly as before, so your custom materialization keeps working. What you lose is static analysis on that node: the engine cannot know whether your materialization changes columns, so it silently skips analysis for it. No error, no warning. You migrate, you believe you have column-level lineage, and on that subtree you quietly do not. Pre-flight every custom materialization before the migration, because nothing in the migration will mention them.
On Snowflake, BigQuery and Databricks, Python models are functional on the v2 engine. They sit outside the static-analysis story for the reason Chapter 21 spent a chapter on: dbt never reads your Python, so a Python model cannot be analysed as SQL. dbt Labs describe that as the last open question before GA. No source says Python models need static_analysis turned off, so this chapter does not say it either.
Python models and dbt beyond SQL — chapter 21The dbt-fusion repository was retired in favour of dbt-core and its issues moved. It is not archived — GitHub reports archived: false — and its status is not evidence about the engine’s future in either direction. Chapter 21 made the same correction about dbt-redshift’s move into the adapters monorepo. A repository’s housekeeping is not a product decision.
The weak answer names two things and gets the licence wrong. The strong answer names four and separates the axes: dbt Core v1.x is the Python implementation under Apache 2.0; dbt Core v2.0 is the Rust runtime, also Apache 2.0, currently an alpha; the Fusion engine is a free binary built on that runtime plus proprietary code, under its own licence; and dbt platform is the commercial SaaS, renamed from dbt Cloud in May 2025. Then land the part that shows you have actually used it: status is per adapter and per surface, Snowflake is GA and Postgres is not supported at all.
Four names, four axes: implementation, licence, distribution, hosting. The runtime is Apache-2.0 and alpha; the Fusion binary is free and proprietary; support status is per adapter and per surface; and there is no announced end for the 1.x line you are running today.