dbt™ v2 is the current major era of dbt™: a Rust rewrite (often called Fusion) that ships as a self-contained binary, connects via ADBC drivers, and is stricter at parse time while keeping familiar project language and DAG semantics. Official docs (2026) treat the move as prepare on latest v1 → fix deprecations → install v2 → validate. You can keep v1.x if packages or tooling are not ready; new capabilities land in v2 only over time.

Prepare on the latest v1 track

Upgrade environments and jobs to the v1 Latest release track first. Resolve every deprecation warning while still on v1—warnings become errors in v2.

• Use dbt-autofix (Studio IDE, VS Code/Cursor extension, or the autofix GitHub repo) to move arbitrary configs into meta, upgrade packages, and clear common YAML issues.

• Remove any flags: overrides in dbt_project.yml that opt out of behavior-change flags; v2 forcibly enables them.

• On dbt Core™ v1.12, dry-run the Rust parser without switching engines:

  dbt parse --use-v2-parser

  dbt parse --use-v2-parser

  dbt parse --use-v2-parser

Confirm packages list require-dbt-version including 2.0.0 (or higher) on the dbt™ package hub. Popular dbt-labs packages (dbt_utils, dbt_project_evaluator, audit_helper, dbt_external_tables) are already v2-compatible; bump others or temporarily remove unready ones.

Install v2 and verify

Upgrading locally is an install step. Recommended distribution is the dbt package (v2 by default). For Apache 2.0-only orgs, use dbt-oss. Stay on v1.x only if you must.

python -m pip install dbt

# or later:
python -m pip install --upgrade dbt
dbt --version
dbt login status   # optional; needed for static_analysis: strict

python -m pip install dbt

# or later:
python -m pip install --upgrade dbt
dbt --version
dbt login status   # optional; needed for static_analysis: strict

python -m pip install dbt

# or later:
python -m pip install --upgrade dbt
dbt --version
dbt login status   # optional; needed for static_analysis: strict

Other installers: Homebrew, curl install script, or winget install --id dbtLabs.dbt --exact.

• v2 adapters are bundled—no separate pip install dbt-<adapter>.

• On first run, dbt™ downloads ADBC drivers from the dbt Labs CDN (public.cdn.getdbt.com) and caches them; use dbt system install-drivers to pre-cache.

• GA adapters include Snowflake, BigQuery, Redshift, and Databricks; ClickHouse (private beta), Spark (CLI beta), and DuckDB (CLI) are also listed. Adapter GA timing can differ between dbt™ platform and local CLI.

Profiles, project config, and side-by-side runs

CLI still uses profiles.yml. Search order: --profiles-dir, then project root, then ~/.dbt/ (recommended). Create or refresh with dbt init, then dbt debug. Profile type remains the adapter name (snowflake, bigquery, databricks, redshift, etc.); credentials stay in the profile/target as before.

In dbt_project.yml:

• Drop opt-out flags:

• Fix unused/unknown config paths (v2 errors on them)

• Prefer explicit static analysis:

models:
  your_project:
    +static_analysis: baseline   # default; warnings only
    # +static_analysis: strict   # needs dbt login; column lineage / type checks

models:
  your_project:
    +static_analysis: baseline   # default; warnings only
    # +static_analysis: strict   # needs dbt login; column lineage / type checks

models:
  your_project:
    +static_analysis: baseline   # default; warnings only
    # +static_analysis: strict   # needs dbt login; column lineage / type checks

Move standalone YAML anchors under a top-level anchors: key; self-referential recursive anchors are unsupported. Access custom meta configs with config.meta_get() / config.meta_require(), not config.get() / config.require().

v2 writes a v12 manifest compatible with v1 (extra v2-only fields are ignored by v1), so you can run v2 and v1 side by side; state:modified, --defer, and cross-environment dbt docs generate work across mixed engines.

Scripts, jobs, and known breaking changes

• Replace --models / --model / -m with --select / -s (v2 errors on the old flags).

• Remove --partial-parse / --no-partial-parse from job commands (warning dbt1700).

• Many historic flags (--print, --single-threaded, --use-experimental-parser, etc.) become no-ops with warnings—clean them from CI.

• Parse fails earlier than v1 on missing macros, adapter methods, generic tests, and undefined var()s.

• Conflicting package version pins between root and local packages error at dbt deps.

• dbt clean no longer deletes resource-path files or paths outside the project.

• Unit tests in dbt build run first, then the rest of the DAG.

• Threading defaults differ by adapter (Snowflake/Databricks auto-manage parallelism; BigQuery/Redshift respect --threads, with 0/omit for dynamic).

After install, validate:

dbt deps
dbt parse
dbt compile
dbt build
dbt test
# optional v2 extras:
dbt lint
dbt freshness
dbt docs generate

dbt deps
dbt parse
dbt compile
dbt build
dbt test
# optional v2 extras:
dbt lint
dbt freshness
dbt docs generate

dbt deps
dbt parse
dbt compile
dbt build
dbt test
# optional v2 extras:
dbt lint
dbt freshness
dbt docs generate

On dbt™ platform: prepare on v1 Latest → upgrade assistant for dev → staging → prod, selecting v2 Stable; rollback to v1 Latest only for production-critical issues.

Full reference: Upgrading to v2 and the v2 readiness checklist.

Automate the migration with Paradime DinoAI agents

The checklist above is mostly mechanical: find deprecations, rewrite flags, bump packages, fix YAML, then re-parse and rebuild. That is exactly what Paradime DinoAI is built for—warehouse-aware agents that can read your dbt™ project, run terminal commands, open PRs, and heal failed pipelines.

1. Clear deprecations in the IDE with Copilot

Open the Paradime Code IDE and use DinoAI Copilot in Agent mode. Attach terminal context from dbt parse --use-v2-parser (or a failing dbt parse after you switch engines), then prompt for a migration pass, for example:

Resolve every v1→v2 deprecation in this project: move arbitrary configs into meta, replace --models/-m with --select/-s, drop opt-out flags: and unknown config paths, relocate YAML anchors under anchors:, and bump packages whose require-dbt-version excludes 2.0.

Review the diff, run parse again, and open a PR from the panel. Commit a .dinorules (and optional .dinoprompts) so every later agent run follows the same v2 conventions.

2. Codify a version-controlled migration agent

For a repeatable, unattended pass, define a Programmable Agent under .dinoai/agents/ (or build it in the Agents app and deploy as YAML). Give it a fixed role/goal such as “dbt™ v2 migration fixer,” allowlist tools for file edits, code search, terminal (dbt parse, dbt deps, dbt build), and GitHub PRs, then trigger it from a Bolt schedule or the Paradime API / Python SDK.

• Attended runs (Copilot, Slack) can ask clarifying questions.

• API and Bolt runs assume and continue—ideal for overnight remediation across large repos.

• Pin the agent to an environment that still runs v1.12 while you prepare, then retarget a v2 environment once packages and CI are clean (Paradime supports per-environment dbt™ versions).

3. Validate on Bolt, then Fix with DinoAI

Point a Bolt schedule at the upgraded project (or a side-by-side v2 environment) and run dbt deps → dbt parse → dbt build. When something fails, open the run’s DinoAI tab and use Fix with DinoAI: it summarises the log, proposes SQL/YAML/config edits, and opens a PR for review. Turn on Self-Healing if you want AutoPilot to attempt the fix and re-run without waiting. After you are on dbt™ 2.0, Paradime State can skip or clone unchanged models so migration validation builds only what changed.

Start from the DinoAI docs—Copilot for interactive fixes, Programmable Agents for automated sweeps, and the Bolt Pipeline Agent for production failures after the cutover.