dbt v2.0 vs dbt Core v1

Should a team on dbt Core v1 move to dbt v2.0 now?

Stay on the v1 line if your project depends on Python runtime behavior, runs on a platform v2.0 does not yet support, or cannot absorb stricter parse-time checks without a review cycle. Python-based dbt Core v1 projects that load custom Python code, rely on the Python packages installed alongside dbt, or run on Windows on ARM should stay put until those dependencies are understood. The v2.0 release is a ground-up rewrite in Rust, so behavior your team has never documented may not carry over. Before deciding, run dbt parse on a branch of your project under v2.0 in a non-production environment and count the errors it reports, then decide whether your deployment window can absorb fixing them. Confirm current platform support against the dbt-labs/dbt-core repository before you commit.

Move to v2.0 when the single binary, Parquet artifacts and supported platforms match your environment. The v2.0 distribution ships as a self-contained binary with no Python runtime, which simplifies CI images and removes a Python environment from the scheduler host. Teams that consume manifest.json or other JSON artifacts keep them, since v2.0 still writes JSON, but any downstream tooling that reads Parquet artifacts needs testing. A useful check is to list every system that reads dbt artifacts, every container image that installs dbt, and every operating system your runners use, then compare that list with the supported platforms in the README.

Both lines received updates on the same day, so the choice is about fit and risk, not version numbers alone. dbt v2.0.8 was published on October 14, 2026, alongside v1.12.6 and v1.11.16 on the v1 lines, so staying on v1 is not a stalled path, and a v1 security or bug fix does not force a v2.0 migration. Plan the decision around who pays for the change: your data engineers test parse-time behavior, your platform team rebuilds images, and your analysts watch for changed model output. Ask your team to document a rollback path for each environment, and keep both versions pinned in your pipeline until the test run is clean.

Which capabilities differ between dbt v2.0 and dbt Core v1

This table compares the capabilities that change when a team moves from the Python dbt Core v1 line to dbt v2.0, the Rust rewrite on the main branch. Read each row as a question to answer for your own environment: whether the install model, parse behavior, artifact formats and operating systems fit your pipelines. The main takeaway is that v2.0 changes the runtime and parsing contract, so the upgrade decision depends on your platforms and downstream consumers of the artifacts more than on the headline features.

Capability	dbt v2.0	dbt Core v1
Runtime and install	Distributed as a single self-contained binary with no Python runtime to manage	Python implementation that requires a Python environment and its dependencies
Parse-time language checking	Enforces a stricter language specification at parse time, so some v1 projects may fail to parse until corrected	Parse-time checks follow the v1 specification, which is more permissive
Artifact formats	Produces Parquet artifacts while still writing JSON artifacts such as manifest.json	Writes JSON artifacts such as manifest.json; confirm any Parquet consumers before changing anything
Platform support	macOS and Linux on x86-64 and ARM, and Windows on x86-64; Windows on ARM is not yet supported	Confirm supported operating systems and architectures for the v1 release line you run in your own environment
Development branch	Source code on the main branch of dbt-labs/dbt-core	Development moved to the 1.latest branch of dbt-labs/dbt-core
Adapter and package parity	Confirm each adapter and package in your project's dependency list supports v2.0 before upgrading	Confirm each adapter and package pinned in your project is maintained on the v1 line you use

How the Apache 2.0 source code and the dbt product license apply to each line

The dbt repository mixes two licensing layers and two development tracks, and the choice between v1 and v2.0 depends on which layer you use and which branch you build from. Read each card before you decide how to redistribute binaries or embed dbt in a product.

Source code under Apache 2.0

The dbt-labs/dbt-core repository states that its source code is available under the Apache 2.0 license. That grant covers the code in the repository, including the v2.0 Rust rewrite on main and the v1 Python code on 1.latest. Confirm that the license file in the exact tag you build from is the one you rely on, because your obligations attach to that snapshot.

Distribution under the dbt product license

The dbt README says that dbt is a distribution of the repository with dbt-specific customizations released under a dbt product license. Those terms may differ from the Apache 2.0 terms on the source. If you ship or redistribute the dbt binary, the product license text is the document that governs that use, so read it before you package anything.

Maintaining v1 on the 1.latest branch

Development of the v1 Python implementation moved to the 1.latest branch when main took the v2.0 rewrite. Teams that stay on v1 should pin to the 1.latest line and track its release notes. The v1 lines received releases on the same day as v2.0.8, including v1.12.6 and v1.11.16, so check which v1 minor version your pipelines depend on.

Developing v2.0 on main

The main branch now holds the v2.0 rewrite in Rust, distributed as a single self-contained binary. Teams that move to v2.0 take on the main branch line and its release cadence, which is separate from v1. Pin the exact v2.0 release you test, since the v2.0 line is newer and its behavior under your existing projects is what your own test suite must confirm.

Support windows for each line

The published release cadence shows recent releases on both lines, but it does not establish how long each line receives fixes. Do not assume a support window from the release dates. Read the dbt product license text and the release notes for each line to find the support window and the upgrade path, and record those dates in your own maintenance plan.

Questions for dbt Labs before redistribution

Before you redistribute binaries or embed dbt in a commercial product, ask dbt Labs in writing which terms apply to your use, whether the product license permits your distribution model, and what attribution or notice duties apply. Ask which customizations are covered, and whether terms differ for the v1 and v2.0 binaries. Have counsel review the answers.

What stricter parsing at parse time can break in an existing v1 project

dbt v2.0 enforces a stricter language specification at parse time, so SQL or Jinja that dbt Core v1 accepted can fail earlier in the run, before any model touches the warehouse. For a team on v1, the practical risk is not a wrong result but a failed parse. In CI, a pull request check that ran dbt parse or dbt build on v1 may go red the first time the same branch is checked with v2.0. Scheduled jobs are exposed in the same way: a nightly run that has been green for months can stop at the parse step after a binary change, which delays every downstream model and any dashboard that reads from them.

The safe path is to run the v2.0 parser against a copy of the project, not the production repository. Check out the current main branch in a scratch environment, point it at a non-production target, and run a parse-only pass. Collect every failure, group them by file and by error type, and triage them before anyone schedules a cutover. Some failures will be trivial syntax fixes. Others will reveal assumptions in the project that v1 quietly tolerated. Keep the v1 pipeline running in parallel until the copy parses cleanly and the team has reviewed the output, including the JSON artifacts such as manifest.json that downstream tools may read.

The size of this effort depends on how much custom Jinja, macros and package code the project carries. A project with plain select models and a few well-known packages will usually need little work. A project with heavy macro libraries, dynamic ref or source patterns, or internal packages written years ago needs a longer review. Confirm which constructs each package uses, and check with each package maintainer whether a v2.0-compatible release exists, because a vendored package that fails the parser is your code to fix. Ask your dbt partner or platform team to document which parse errors they expect before scoping the work, and treat the triage list as the input to any fixed-scope plan.

Which operating systems and chip types dbt v2.0 supports today

The dbt README states that dbt v2.0 supports macOS and Linux on x86-64 and ARM, and Windows on x86-64. For most analysts and analytics engineers, this covers the common laptop fleet, so a laptop change is usually the easiest part of a move to v2.0. Your developer environment still needs to match what your team uses to build and test models.

Supported combinations: macOS on x86-64 and ARM, Linux on x86-64 and ARM, and Windows on x86-64 are listed as supported for v2.0.
Single binary: v2.0 ships as one self-contained binary with no Python runtime, so developers no longer need a matching Python environment on each machine.
Stricter parsing: Models that parsed under v1 may fail at parse time under v2.0, so run the parser locally before the rest of the team switches.
Keep v1 where required: If a developer machine relies on a Python-based dbt plugin or a workflow that v2.0 does not yet cover, keep that machine on v1 until the dependency is confirmed.
Test on the same OS image: Run the binary on the same operating system version your laptops use, not only on the newest release.

Before you roll out v2.0 to laptops, confirm the current support status in the dbt-labs/dbt-core release notes, since platform support can change between releases.

What Parquet artifacts change for teams that read dbt output

dbt v2.0 writes Parquet artifacts and still writes JSON artifacts such as `manifest.json`, according to the dbt README. That means a reader that already parses manifest.json or run results should keep working after an upgrade, but the Parquet files are new output that some consumers may pick up if they glob a whole target directory. Before you change anything, list every system that reads dbt output: data catalogs, lineage tools, cost dashboards, CI checks and custom scripts. For each one, confirm which file it reads, whether it reads JSON or Parquet, and whether it would be affected if a new file appeared next to the old ones.

Affected teams are rarely the ones writing models. The people most likely to notice a change are the owners of catalogs, lineage imports and cost reporting, because those pipelines often run on a schedule and fail quietly. Ask each owner to write down the artifact name, the fields they rely on and the job that consumes it. A consumer that reads only manifest.json by exact path is low risk. A consumer that scans a directory, or that expects one file per run, needs a specific test before the switch.

Run the v2.0 binary against a staging project and compare every consumer's output with the v1 baseline. Confirm that the JSON artifacts match what the consumer expects, and test every Parquet read your team plans to adopt. The facts available to this page do not describe Parquet schema, column names or how fields map to the JSON structure, so confirm those details in dbt Labs' documentation and in the dbt-core releases page for the version you plan to deploy before you rely on any field in production.

What each path costs in engineering time, infrastructure and licensing

This table separates the cost components of staying on dbt Core v1, moving to dbt v2.0 and paying for the dbt platform. Read the one-time rows as migration effort and the recurring rows as what you pay every month. The main takeaway is that the supplied facts show no separate license fee for the open-source binary, so engineering effort is the largest variable.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Engineer time for parse-time fixes	Your data platform or analytics engineers, or a partner under a written scope	One-time for the migration, then recurring when upgrades surface new parse errors	Count of models and macros, how many use loose syntax that v2.0 rejects at parse time, and test coverage
Engineer time for test runs and comparison	Your analytics engineers, who compare v1 and v2.0 outputs and artifacts	One-time during parallel running, then recurring for each upgrade cycle	Number of models whose outputs must match, and whether artifact consumers read JSON or Parquet
CI runner time for parallel v1 and v2.0 pipelines	Your cloud or CI provider, billed on runner minutes you consume	Recurring while both pipelines run, then lower after cutover	Length of the parallel period, build duration per pipeline, and how many branches trigger both jobs
Build image and deployment packaging changes	Your platform engineers, who replace Python-based images with a single binary	One-time for the image rebuild and release process, then recurring for patching the binary	Whether existing images bundle Python packages and plugins, and how your deployment pipeline pins versions
Adapter and dependency verification	Your engineers, plus any adapter maintainers you rely on	One-time per adapter, then recurring when adapters update	Number of warehouse adapters in use and whether each one supports your v2.0 targets; confirm this with the adapter maintainers
Open-source binary license	Not separately listed in the supplied facts; the dbt README describes the source as Apache 2.0 and the dbt distribution under a dbt product license	Confirm in writing whether any fee applies to your use of the dbt distribution	Which distribution you run and whether your use falls under the dbt product license terms
dbt platform Developer plan	dbt Labs, per the dbt pricing page	Recurring if chosen; free tier with one developer seat, 3,000 successful model builds a month and one project	Developer seat count, monthly model builds and number of projects
dbt platform Starter plan	dbt Labs, per the dbt pricing page	Recurring at $100 per user per month, with five seats and 15,000 builds a month	Seat count per user, monthly build volume and the features you need beyond the Starter limits
dbt platform Enterprise and Enterprise+	dbt Labs, at custom pricing per the dbt pricing page	Recurring, quoted; the pricing page lists 100,000 successful builds and 20,000 queried metrics a month on both	Project count (30 on Enterprise, unlimited on Enterprise+), build volume and support terms; request these in the quote

How to move a v1 project to v2.0 without a broken release

This sequence lets a team prove that its dbt project, its packages and its downstream artifact readers work on dbt v2.0 before any production run depends on it. It ends with a cutover that keeps the v1 build available for rollback.

Inventory the project, packages and artifact readers
The analytics engineering lead lists every model, macro, test and seed in the project, every installed package and the dbt version each one pins. The platform or data engineering team adds every tool that reads dbt output, such as catalogs, BI semantic layers, CI checks and custom scripts that parse manifest.json or run_results.json. Each reader gets an owner. The step is done when the list is in version control and every consumer has a named owner who has confirmed it reads dbt artifacts.
Check target platforms against the supported list
The platform engineer compares the operating systems and CPU architectures on which dbt runs today with the v2.0 support list in the dbt README: macOS and Linux on x86-64 and ARM, and Windows on x86-64. Windows on ARM is not yet supported. Any developer laptop, runner image or container base that falls outside the list stays on the v1 line for now. The step closes with a written matrix of platform, architecture and dbt line, signed off by the team lead.
Run the v2.0 binary in a non-production CI job
The data platform engineer creates a CI job that installs the v2.0 single binary, which needs no Python runtime, and runs parse, compile and build against a copy of the production project and a non-production warehouse target. The job uses the same adapter and credentials pattern as production, with write access limited to a sandbox schema. The step is done when the job runs green on a clean checkout and its logs and version output are archived for the change record.
Fix stricter parse-time failures
The analytics engineers work through each parse failure the v2.0 run reports. dbt v2.0 enforces a stricter language specification at parse time, so syntax that v1 accepted may now stop the run. Each fix goes into a branch with a pull request and a note in the change log that links the original error to the corrected code. Engineers rerun the job until the parse and build pass on the full project. Ask the vendor or the dbt-labs/dbt-core release notes which specification rules changed before estimating how many fixes the project needs.
Test Parquet and JSON artifacts with each consumer
The data platform engineer confirms that v2.0 still writes JSON artifacts such as manifest.json and also writes Parquet artifacts. Each reader from the inventory is pointed at the new output in the sandbox. Consumers that expect JSON keep reading JSON, and any consumer that will move to Parquet is tested on a branch. The owner of each reader signs off that its ingest, lineage or documentation step produces the same result as on v1. Differences go to a defect list that must be empty before cutover.
Run a parallel schedule for one release cycle
The platform team schedules the v2.0 build alongside the v1 build for the same models and compares row counts, test results and artifact contents on each run. The number of cycles depends on the team's release calendar, its change freeze windows and its risk tolerance, so the length of the parallel period should be agreed in writing with the data owners before it starts. The step is done when parallel runs match on the agreed cycle and the comparison report is filed.
Cut over with a documented rollback path
The release manager switches the production orchestrator to the v2.0 binary on an agreed date and records the exact dbt version, the image digest and the configuration change in the change ticket. The team keeps the v1 build image in the registry and documents the commands that restore it, along with the owner who can run them. The cutover is complete when the first production schedules pass, the artifact consumers confirm their reads, and the rollback runbook has been tested in the sandbox.

What buyers and practitioners ask before moving from dbt Core v1 to v2.0

Can our team move from dbt Core v1 to v2.0 without outside help?

Yes, for smaller projects run by an engineer who already knows dbt well. The deciding factor is how much of the project depends on Jinja macros, custom logic and third-party packages, because those are where v2.0's stricter parsing is most likely to surface problems. A project with a few dozen models, few custom macros and standard packages is a reasonable self-move candidate. A project with heavy macro layers, undocumented behavior or many packages should be scoped with someone who has done a migration before. Start by running the existing project against v2.0 in a non-production environment and count the errors before deciding who does the work.

How long does a dbt Core v1 to v2.0 migration take?

The supplied information does not give a duration, so no timeline should be assumed. The practical way to size the work is a test run: point a copy of the project at v2.0 and record how many parse errors, failing models, package incompatibilities and changed artifacts appear. Those counts, along with the number of macros and packages, give a basis for estimating effort. Ask any implementation partner for a written scope that lists the test run as a deliverable and states the timeline that follows from its results, rather than accepting an estimate made before the test run.

What does a dbt v2.0 migration need from our side?

Plan for four things before the work starts:

A CI pipeline that runs the project build and tests on every change, so regressions show up before merge.
A staging warehouse that mirrors production schemas closely enough to compare model outputs.
An inventory of every consumer of dbt artifacts, such as catalog tools, orchestrators, and scripts that read manifest.json. v2.0 still writes JSON artifacts, but it also writes Parquet, so confirm each consumer handles what it expects.
A rollback plan that keeps the v1 environment and pinned versions available until the outputs are verified.

These needs apply whether an internal team or an outside firm performs the work.

Does dbt Core v1 stop receiving updates once v2.0 is available?

Confirm this with dbt Labs before making a decision, because no end date for the v1 support window was included in the information available for this page. The public repository shows that v1 patch releases were still being published on the v1 lines alongside v2.0.8 in October 2026, and that Python v1 development moved to the 1.latest branch. Check the dbt-labs/dbt-core releases page and dbt Labs' release notes for the current support policy, and record the date in your upgrade plan so that a security or compatibility fix on the v1 line does not catch you unprepared.

Does the dbt product license affect internal use of dbt v2.0?

It can, so confirm it with the license text and your legal counsel before you deploy. The dbt README states that the repository's source code is available under the Apache 2.0 license, but that the dbt distribution contains dbt-specific customizations released under a dbt product license. Those two terms are not the same thing. Teams that build from the Apache 2.0 source may face different terms from teams that install the distributed dbt product, so identify which build you will run, which license governs it, and whether any internal use case, such as embedding or redistribution, falls outside the grant.

What makes the dbt v2.0 migration take more or less effort?

The main drivers are:

Macro and package complexity, which determines how many models break under stricter parsing.
Test coverage, since good tests make regressions visible quickly and reduce manual comparison.
Number of downstream consumers of dbt artifacts and the orchestrator or BI tools that read them.
Platform mix, because v2.0 supports macOS and Linux on x86-64 and ARM and Windows on x86-64, but not Windows on ARM. Teams on Windows on ARM need a different path.
Team familiarity with Rust-based tooling, which matters less than familiarity with the project itself.

Costs recur only where you pay for runners, staging warehouses or outside support, so ask any quote to separate one-time migration work from ongoing upgrade support.

How DeployOpen scopes and delivers a dbt version move

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a move between dbt Core v1 and dbt v2.0 is handled as a written, fixed-scope change to your existing transformation estate. The work starts with an inventory of what your projects, runners and downstream consumers actually depend on.

How we scope

Inventory of dbt projects, packages, adapters and the Python versions your runners currently use
Written list of which models, macros and tests need changes for the stricter parse-time language rules
Agreed decision on Parquet artifact consumers and whether JSON artifacts remain in use
Confirmed platform targets, including whether any Windows on ARM machines are in the build fleet

How we build

Single-binary install configured in your CI runners and developer environments, with versions pinned
Parse-time failures triaged and fixed in source models, with each change traced to a documented rule
Test suites run against both the v1 and v2.0 lines to confirm identical warehouse output
Orchestrator job definitions updated for the new binary, with artifact paths checked end to end

How we hand over

Written runbook covering installation, version pinning, upgrade and rollback steps for your team
Licensing summary that separates the Apache 2.0 source code from the dbt product license terms you accept
Documentation of changed artifact formats, with examples of how downstream tools read them
Walkthrough sessions with the engineers who will own the pipeline after handover

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainer scope agreed in writing, covering tracking of v1 and v2.0 patch releases in your environment
Review of each new release against your documented dependencies before you adopt it
Confirm with your team which support window and terms apply to each dbt line before committing