dbt v2 Is Generally Available: What the New Engine Changes for an Existing Project

dbt v2 is now generally available. dbt Labs announced the change in a Developer Blog post dated 16 September 2026: the Rust-based engine previously called the dbt Fusion engine graduated to general availability under the name “dbt”. For teams with a working dbt v1 project, the question is no longer whether v2 exists, but what it changes in day-to-day behaviour and how to move without breaking production.

This article focuses on the engineering changes: stricter validation, new commands, the two v2 distributions, adapter coverage and running v1 and v2 side by side. It complements our earlier piece on naming, and it ends with a practical runbook.

What changed in September 2026

The dbt v2.0 GA announcement describes a rewrite of the engine rather than an incremental release. Three points matter for planning:

• A new engine. v2 is a Rust binary. The v2 upgrade guide states that adapters connect through Arrow Database Connectivity (ADBC) drivers, and that dbt ships as a single self-contained binary with no Python runtime.
• The same project language. The dbt and dbt OSS comparison states that both v2 distributions share the same language specification, so SQL and YAML behave the same in either.
• v1 is not switched off. The upgrade guide says older projects can stay on v1.x, which “remains fully supported”. The comparison post adds that dbt Core 1.13 is the final minor release to add meaningful functionality to the Python codebase, with security and installation patches continuing and no hard end-of-life date yet.

The practical consequence is that teams have time, but not unlimited time. New capability will land in v2. A v1 project that stays where it is will keep working, and it will gradually fall behind.

Two distributions, different feature sets

v2 comes in two distributions. Choosing between them is a licensing and capability decision, and it should be made before the upgrade, not after.

Area	dbt (package dbt)	dbt OSS (package dbt-oss)
Licence	Free to use under dbt Labs’ own licence terms	Apache 2.0 only
Running a project, new docs site, dbt Information Schema, checks	Included	Included
SQL comprehension, linting, language server (LSP)	Included as free local features	Not included
Seat-based paid features such as dbt Mesh and dbt Catalog	Available	Not available
Usage-based paid features such as dbt State	Available	Available

The comparison post recommends the full dbt distribution for most users. It names two reasons to choose dbt OSS: a company policy that requires Apache-licensed software, or building your own tooling on the open codebase. It also notes that pip install dbt-core still works and installs dbt OSS, which is worth knowing before a CI pipeline silently changes distribution.

Our recommendation is to let legal review the dbt licence terms before adopting the full distribution, and to record the chosen distribution in each repository. Paid features depend on your dbt Labs agreement, so confirm entitlements separately.

Strict validation moves errors to parse time

The most visible change for engineers is stricter validation. According to the upgrade guide, v1 silently ignored misspelled configs, unexpected YAML keys and invalid flags. In v2 these raise explicit errors at parse time. The guide lists several failures that move from compile time to dbt parse:

• references to macros or adapter methods that do not exist;
• generic tests that are not defined;
• undefined variables, such as var('does_not_exist');
• duplicate docs blocks with the same name;
• unexpected top-level YAML keys, with standalone anchors moving under a new anchors: key.

Other behaviour changes are subtler. In dbt build, all unit tests now run first, before the rest of the DAG. compile skips only the downstream nodes of a failure and keeps compiling the rest. Reading custom keys stored in meta through config.get now returns the default with a warning; the guide points to config.meta_get and config.meta_require instead. On Snowflake and Databricks, dbt manages parallelism and threads acts as a cap.

This is a net gain for reliability. Errors that once reached the warehouse, or failed halfway through a nightly run, now stop at parse. The cost is a one-off clean-up: a mature v1 project often carries years of tolerated mistakes, and each one becomes a blocker.

New commands and artefacts worth adopting

v2 adds capabilities that change how teams test and document projects. The upgrade guide describes, among others:

• Checks. SQL rules in a checks/ directory, run with dbt check and on every dbt build. They are included in both distributions.
• dbt Information Schema. With --generate-info-schema, dbt writes versioned Parquet files under target/info_schema/. The metadata grows as the project is parsed, compiled and run.
• Docs v2. dbt docs generate produces Parquet artefacts and a static site that uses DuckDB-WASM in the browser, so it can be hosted on any static file host.
• Model freshness. Freshness thresholds can be set on models, checked with dbt freshness. dbt source freshness remains for compatibility.
• Static analysis. In the full distribution, baseline mode parses SQL without a warehouse connection and reports warnings. strict mode resolves column types and is required for column-level lineage; the guide states that it requires dbt login and falls back to baseline when unauthenticated.

The last point deserves attention in regulated environments. A feature that needs a sign-in to dbt Labs may be acceptable on developer laptops and not in a restricted CI runner. Decide where strict analysis runs, and what happens when it silently falls back to baseline. If downstream tools such as DataHub consume dbt artefacts, test that ingestion still reads what it needs from v2 output.

Batch tests are another option worth evaluating. The guide describes a --batch-tests flag for dbt test and dbt build that groups tests into fewer queries. Measure its effect on your own warehouse before enabling it in production jobs.

Adapters and platforms: check yours first

Adapter coverage is the most common blocker. The supported data platforms page and the supported features page list BigQuery, Databricks, Redshift, Snowflake, ClickHouse (private beta), Apache Spark (CLI only, beta) and DuckDB (CLI only). Both pages note that adapter lifecycle can differ between the dbt platform and local development.

PostgreSQL and Trino were not listed for v2 on the research date. Teams running dbt against Trino or PostgreSQL should treat v1.x as their production line until their adapter appears with a status they accept. Community adapters are listed separately by dbt Labs, and their v2 status needs checking adapter by adapter.

The supported features page also lists known gaps: models that rely on materialisation features v2 does not fully support, tooling that depends on v1’s exact log output, and SQLFluff, which is not natively compatible with v2. If your CI parses dbt logs or runs SQLFluff, plan for changes there too.

Running v1 and v2 side by side

A big-bang switch is rarely necessary. The upgrade guide states that v2 writes manifest v12, which is compatible with v1, and that v2-only fields are ignored by v1. It also states that state:modified, --defer and cross-environment dbt docs generate work across both.

That allows a staged approach. Production can stay on v1.12 while a CI job runs the same project on v2 and compares results. On v1.12, the opt-in --use-v2-parser flag delegates parsing to the v2 parser and changes nothing else, which is a low-risk first test. Once results match and the adapter status is acceptable, production can move, with v1 kept available for rollback.

An upgrade runbook

The following order is based on the upgrade guide and fits most projects:

1. Record the target distribution (dbt or dbt-oss) and confirm the licence choice with legal.
2. Confirm v2 status for every adapter and authentication method you use, locally and on the dbt platform.
3. Upgrade to the latest v1 and resolve every deprecation warning, including historic ones.
4. Run dbt parse --use-v2-parser on v1.12 and fix what it reports.
5. Apply dbt-autofix or the dbt Labs migration agent skill, then review every change in a pull request.
6. Replace --models and -m with --select and -s, and remove --partial-parse flags from job commands.
7. Fix YAML anchors, duplicate docs blocks and meta access in macros.
8. Check that each package’s require-dbt-version includes 2.0.0.
9. Run dbt build on v2 in a non-production environment and compare row counts, test results and run times with v1.
10. Update CI for logs, linting and any tool that reads dbt artefacts, then cut over with a rollback plan.

For larger estates with many projects, sequence the upgrade by risk. Start with a project that has good test coverage and a well-supported adapter, then move to projects with heavy macro use, custom materialisations or many packages. Keep a shared log of the issues found and how they were fixed; most will repeat across projects.

Treat each step as a change with an owner and evidence. The parse clean-up is usually the largest step, and it is also the one that delivers lasting value.

How Bassirah can help

We help teams assess v2 readiness, choose between the dbt and dbt OSS distributions, and run staged upgrades with side-by-side comparison before cut-over. Our support for dbt OSS is independent engineering; upstream fixes follow the community’s timeline, as described in our open-source support model. See our dbt page and analytics engineering for how we work.