From dbt Core v1 to dbt v2 on Snowflake: A Practical Migration Guide

A practical guide to preparing an existing Snowflake dbt project for v2, validating compatibility, and handling static-analysis gaps.

dbt v2 became generally available on September 16, 2026 (dbt Labs’ announcement), bringing the engine developed under the “Fusion” codename into the productized version of dbt.

When I started looking into what it would take to move an existing Snowflake dbt project to v2, I expected the engine change itself to be the difficult part. What became more important was the preparation: getting the project ready on v1 first, checking compatibility before switching, and separating documented migration guidance from the smaller environment and SQL issues you may discover along the way.

This post focuses on that practical migration path.

By the end of this post, you’ll know:

• The core architectural change between dbt v1 and dbt v2
• What dbt v2 adds, including static analysis and performance improvements
• dbt Labs’ recommended migration sequence — prepare on v1, then switch, then validate
• One Snowflake SQL compatibility gap worth checking after switching

TL;DR

For an existing Snowflake dbt project, the migration path is:

Upgrade to dbt v1.12 → resolve deprecations and check package compatibility → run dbt parse --use-v2-parser → switch to dbt v2 → compile and test the project.

The key is to use v1.12 as the preparation step rather than treating the migration as a direct package replacement. After switching, static analysis may also surface warehouse-specific SQL that v1 did not flag, so validate the full project and distinguish parser limitations from actual Snowflake runtime issues.

Migration path at a glance

What actually changes

In dbt v1, the toolchain is split into two independently versioned packages: dbt-core (the Python engine — Jinja rendering, DAG resolution, the CLI) and a separate adapter package per warehouse, like dbt-snowflake. These ship on their own release cadences and coordinate through a defined adapter interface, so compatibility between the core engine and the warehouse adapter needs to be managed as part of the v1 setup.

dbt v2 collapses that into a single package. Per dbt Labs, “all v2 adapters connect to data warehouses via the Arrow Database Connectivity (ADBC) standard instead of Python-based adapter libraries” (Upgrading to v2). For Snowflake, that means no separate adapter package to install or version-match:

- dbt-core>=1.10,<1.11
- dbt-snowflake>=1.10,<1.11
+ dbt>=2.0,<3.0

dbt v2 also adds a second compilation phase beyond Jinja rendering: static analysis, which builds and validates a logical query plan for your SQL before anything runs against the warehouse. That’s what unlocks column-level lineage and stronger validation — and it’s the source of the compatibility note near the end of this post.

Why move to dbt v2?

The migration work brings meaningful improvements. dbt v2 introduces local SQL compilation and static analysis, allowing more SQL errors and downstream impacts to be identified before queries reach Snowflake. Because dbt understands the project graph as well as the SQL itself, this analysis can also support capabilities such as column-level lineage and help surface the downstream impact of changes earlier in the development cycle.

The Rust-based engine is also designed to improve parsing and compilation performance, which can make a noticeable difference in larger or highly customized dbt projects. dbt v2 also integrates with dbt State, helping reduce unnecessary execution by identifying models that can be skipped or, where applicable, cloned instead of rebuilt.

Together, these changes can shorten the development feedback loop and catch more problems before warehouse execution — increasingly useful as both developers and coding agents generate SQL more quickly.

The recommended migration path

dbt Labs documents a specific sequence for moving an existing v1 project to v2, and it’s worth following in order rather than jumping straight to installing v2.

1. Prepare while still on v1

The starting point isn’t your current v1 version — it’s the latest one. dbt Labs is explicit about this:

“The best way to prepare to migrate is to first upgrade to dbt v1.12 (or the ‘Latest’ release track in the dbt platform).” — dbt Core v2 is here

v1.12 matters specifically because it enforces many of the behavior changes that become mandatory in v2, and it ships with an opt-in flag that lets you test v2’s parser without actually switching engines yet.

Once you’re on v1.12, three things are worth doing before you touch v2 at all:

• Resolve deprecation warnings. The upgrade guide treats this as a precondition: “All deprecation warnings must be resolved before upgrading to the new engine.” Many of these are auto-fixable with dbt-autofix, a tool dbt Labs publishes specifically for this.
• Check third-party package compatibility — via each package’s require-dbt-version setting or the v2-compatible badge on the dbt package hub.
• Test the v2 parser without switching engines, using the opt-in flag available on v1.12:

dbt parse --use-v2-parser

This “delegates parsing to the v2 parser without changing any other behavior, making it a low-risk way to catch compatibility issues early” (Upgrading to v2). Fix whatever it surfaces while you’re still safely on v1.

2. Switch to v2

dbt Labs’ own signal for when you’re ready is straightforward: once that parser check passes cleanly, install v2.

“Run dbt parse --use-v2-parser to try it out. If your project succeeds, you’re good to go, and should check out the installation guide to switch over.” — dbt Core v2 is here

For a fresh environment, install dbt via pip, Homebrew, or a curl-based install. Homebrew/curl install a self-contained binary outside of any Python environment; pip installs dbt as a Python package into whatever environment is active. dbt Labs’ own preference leans toward the binary install, but pip is fully supported and the right choice if your tooling specifically needs dbt resolvable from a Python environment — for example, some IDE integrations select dbt from a project’s virtual environment rather than from $PATH.

One practical note for existing pip-based environments: based on our migration experience, we recommend recreating the virtual environment rather than layering dbt v2 onto an environment that already contains the v1 Python packages. This is a practical recommendation rather than a documented dbt Labs migration requirement, and it gives the project a clean, reproducible environment based on its declared dependencies:

rm -rf .venv
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

3. Validate on v2

After switching, run a full project compile, not just a spot check — v2’s stricter parsing surfaces things v1 never checked, and it’s better to see all of them at once. Then run your actual test suite (dbt build or dbt test) to confirm runtime behavior, since static analysis alone doesn't execute anything against the warehouse.

Static analysis defaults to baseline mode, where findings are warnings, not build-breaking errors:

“Your project can continue running even when the compiler flags invalid or problematic SQL.” — About static analysis

That same page treats unsupported SQL as an expected, normal part of migrating, and asks users to report gaps so parsers can improve.

A compatibility gap worth checking for

One specific gap we ran into during validation: dbt v2’s parser doesn’t yet fully understand Snowflake’s GET_PRESIGNED_URL() function when the stage argument is passed as a bare identifier. This isn't just something we noticed — dbt Labs' own Supported Snowflake functions reference explicitly lists GET_PRESIGNED_URL as unsupported for type-checking today.

Snowflake’s syntax documentation shows the unquoted form as the standard example:

GET_PRESIGNED_URL(@my_stage, 'path/to/file.csv', 3600)

Quoting the stage name is only documented as necessary when it contains spaces or special characters. In practice, wrapping the stage reference in quotes satisfies dbt v2’s current parser and clears the warning, without changing behavior:

-- Compiles cleanly under dbt v2's current baseline static analysis
GET_PRESIGNED_URL('@my_stage', 'path/to/file.csv', 3600)

In our validation, this behaved as a parser-satisfying change rather than a runtime behavior change: both syntaxes returned identical presigned URLs against Snowflake, and running the actual model and fetching the resulting file confirmed it resolved correctly at runtime.

Worth framing this precisely: it’s a workaround for where dbt v2’s parser coverage happens to be today, not a Snowflake-documented requirement or an official dbt fix. If you hit something similar, the better long-term move — per dbt Labs’ own guidance — is to open an issue with the specific SQL that failed to parse.

Practical recommendations

• Don’t skip the v1.12 stepping stone. Testing with --use-v2-parser while still on v1 is a low-risk way to find compatibility issues, and dbt Labs built it for exactly this purpose.
• Run dbt-autofix before switching, not after — it handles many deprecations automatically.
• For existing pip-based setups, consider recreating the virtual environment rather than layering v2 onto an existing v1 environment. Treat this as a practical environment-management recommendation, not a dbt Labs migration requirement.
• After switching, compile the whole project and run your test suite — not just a single model — and don’t assume a static-analysis warning means broken SQL. Check whether the function you’re using appears in dbt’s Snowflake function-support reference before spending time on a workaround.

Conclusion

dbt Labs’ documented path — prepare on the latest v1 release, validate with the v2 parser before switching, then confirm on v2 with a full compile and test run — turns what could be a risky jump into a predictable, low-drama migration. One area worth watching is SQL comprehension coverage for warehouse-specific functions. Under the default baseline static-analysis mode, unsupported or problematic SQL can surface as warnings without necessarily blocking the build, giving teams a chance to investigate parser gaps separately from actual runtime failures.

References

• dbt v2 is GA — dbt Labs’ official GA announcement (September 16, 2026)
• dbt Core v2 is here: still open source, now rebuilt for what’s next — the recommended v1.12-first migration path and the --use-v2-parser readiness check
• Upgrading to v2 — official upgrade guide: ADBC adapter architecture, deprecation-resolution requirements, package compatibility
• Install dbt — official install instructions for dbt v2 (pip, Homebrew, curl)
• About static analysis — baseline vs. strict static analysis modes and guidance for unsupported SQL
• Supported Snowflake functions in dbt v2 — official function-support matrix, refreshed weekly
• dbt-autofix — official dbt Labs tool for automating v1-to-v2 deprecation fixes
• dbt Fusion GitHub Issues — official channel for reporting SQL that dbt v2’s parser doesn’t yet support
• Snowflake: GET_PRESIGNED_URL — official syntax reference

From dbt Core v1 to dbt v2 on Snowflake: A Practical Migration Guide was originally published in Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.