dbt Core v2: Rust Engine, 30x Faster Parsing, Upgrade Guide

dbt Core v2.0 is in alpha, and the number everyone is quoting is 30x faster parse times. That number is real. A 100,000-model project that took 20 minutes now finishes in under 10 seconds. But the performance story is not the reason you should be paying attention right now. The reason is that several deprecated flags are disappearing in v2, behavior changes are locking in, and September 1 is when even more of them become enforced on the Latest release track. The good news: you can surface every incompatibility today with a single flag in dbt Core 1.12.

What Actually Changed Under the Hood

dbt Core v2.0 replaces the Python runtime with a Rust engine — the same Fusion engine that was previously exclusive to dbt Cloud. dbt Labs has open-sourced a substantial portion of Fusion’s runtime under the Apache 2.0 license, which makes v2 the most genuinely open version of dbt yet.

The performance gains come from two structural changes. First, Rust eliminates the Python Global Interpreter Lock (GIL) bottleneck — the core reason that large dbt projects parse slowly today. Second, the new engine uses true parallel parsing, so multi-core machines actually benefit from their cores. Minijinja (dbt’s Jinja implementation in Rust) evaluates a ref() call 30x faster than the Python parser can even begin static analysis.

Beyond parsing speed, v2 also ships Parquet artifacts as a high-performance alternative to the JSON manifests that have always made large dbt projects slow to load in documentation tools. And the language spec is now stricter — a typo in dbt_project.yml that used to be silently ignored is now a hard error. Whether you call that a feature or a breaking change depends on how many quiet typos are sitting in your config right now.

Try the v2 Parser Today — No Risk, One Flag

You do not need to wait for dbt Core v2.0 GA to find out if your project is compatible. dbt Core 1.12 (currently RC3) ships the --use-v2-parser flag, which delegates parsing exclusively to Fusion’s Rust engine while leaving every other behavior unchanged.

# Test Fusion parser compatibility today (dbt Core 1.12+)
dbt parse --use-v2-parser

# Surface all deprecation warnings as hard errors
dbt run --warn-error

This is the fastest compatibility check available. Run it against your production project. Anything that surfaces here will need fixing before you can move to v2. Running it now while GA is months away is smart; running it the week before migration is stressful.

Four Things That Break in v2 — Fix These First

dbt Core v2.0 removes deprecated functionality without a grace period. These four issues will cause hard failures if you do not address them before upgrading.

1. Replace --models with --select

The --models, --model, and -m flags are gone. v2 raises an error — not a warning — when you pass them. Check every job definition, CI pipeline script, and Makefile you own.

# Find scripts still using the deprecated flag
grep -r "\-\-models\|-m " scripts/ ci/ .github/

2. Check Jinja Macros That Test for None

In dbt Core v1.x, get_relation() returns None at parse time. In v2, it returns a relation object with the fully qualified name. Any macro that branches on if relation is none will behave differently. This is the kind of change that fails silently in testing and loudly in production.

3. Resolve All Deprecation Warnings from v1.10+

v2 does not upgrade past unresolved deprecation warnings. Run dbt --warn-error on your current version and treat every warning as a bug. If you are below v1.10, get current first.

4. Audit Behavior Change Flags Before September 1

Several behavior change flags that you could previously opt out of in dbt_project.yml are permanently enabled in v2. More will be enforced by default on September 1, 2026, for teams on the Latest release track. Check the behavior changes reference for the full list and verify your project handles each one correctly.

What Is Actually Free

The open-source picture is more nuanced than the announcement blog suggests, and data teams making infrastructure decisions need to understand it.

dbt-core — the pip package most teams install — ships under the Apache 2.0 license and includes the Rust parser in v2. The runtime code that was previously under Elastic License v2 is now Apache 2.0. That is a genuine improvement.

Column-level lineage in the IDE, the VS Code extension’s real-time validation, dbt lint, and deeper static analysis features require the proprietary Fusion distribution. Those are dbt Cloud or paid-tier features.

There is also a background context worth naming: dbt Labs and Fivetran completed their merger on June 1, 2026. Fivetran now owns both dbt and SQLMesh — dbt’s most direct open-source competitor. The concern is not today’s license. It is where engineering investment flows over the next two years, and whether dbt Core remains a first-class product or becomes a feature-frozen on-ramp to a paid platform. That is worth factoring into dependency decisions.

The Upgrade Path

dbt Core v2.0 is not yet stable. Do not run it in production. Here is the recommended sequence:

1. Run dbt --warn-error now and resolve every warning in your current version.
2. Move to dbt Core 1.12 when it reaches GA (RC3 is out; GA is close).
3. Run dbt parse --use-v2-parser against your project to catch incompatibilities.
4. Fix the four categories above: flags, get_relation(), deprecations, behavior flags.
5. Test dbt Core v2.0 alpha in a staging environment once your checks pass.
6. Wait for v2.0 GA before promoting to production.

The 30x speedup is genuinely worth having. Large data teams running CI on thousands of models spend real money on compute waiting for dbt to parse. Fusion eliminates that bottleneck. But the migration cost is real too, and the official upgrade guide is worth reading in full before you start.