# dbt Core v2.0: a Rust rewrite on the main branch, and what that means for your v1 project

> dbt Core is the Apache 2.0 distribution of dbt; the main branch now hosts v2.0, a Rust rewrite in beta, while the Python implementation lives on the 1.latest branch. The rewrite changes install shape, artifact format and language strictness more than it changes the modelling workflow.

**dbt-labs/dbt-core** — dbt enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications.

- Repository: https://github.com/dbt-labs/dbt-core
- Website: https://getdbt.com
- Stars: 13,933 · Forks: 2,594
- Language: Rust
- License: Apache-2.0
- Published: 2026-08-22 · Updated: 2026-08-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/dbt-labs-dbt-core

## What dbt Core v2.0 is, and who the main branch is now for

dbt Core is the baseline distribution of dbt: analysts write select statements, and dbt turns them into tables and views in a warehouse, resolving dependencies between models, generating documentation, and running tests. It is Apache 2.0 licensed, and the README frames the choice between distributions plainly: pick dbt Core if you need an Apache 2.0 licensed tool and the ability to review every line of code inside it.

The repository's main branch no longer holds the Python implementation. The README carries a warning that dbt Core v1 development has moved to the 1.latest branch, and that main now hosts dbt Core v2.0 in beta, described as a ground-up rewrite in Rust that forms the foundation of the Fusion engine. That is the single most important fact for anyone arriving from a search for the project: the code you get from a default clone is not the code that most existing dbt projects run on. If your team's mental model of dbt is a Python package you pip install, that model now maps to a branch, not to HEAD.

The project's pyproject.toml still declares Development Status :: 3 - Alpha, which sits oddly beside a README that calls the same code beta. Treat the stricter of the two as the honest signal. This is not a tool to put in front of a production warehouse without a rollback story.

## How the Rust rewrite is structured: crates, Parquet artifacts and a stricter parser

The Cargo workspace lists well over fifty crates, and their names map closely to the pipeline stages a dbt run passes through. dbt-loader and dbt-parser handle project loading and parsing; dbt-dag builds the dependency graph; dbt-jinja wraps a vendored minijinja plus separate crates for filters, context and variables; dbt-compilation, dbt-scheduler and dbt-adapter-engine drive execution; dbt-metadata and dbt-metadata-parquet produce artifacts; dbt-docs-core and dbt-docs-server back the local documentation experience. Several crates are explicitly grouped under a Source Available comment in the workspace file, which is a distinction worth noting separately from the Apache 2.0 licence on the repository as a whole.

The data flow the README describes is the same one v1 users know: models reference each other, dbt resolves the order, and the warehouse does the work. What changed is what happens before and after that. The README states that v2.0 enforces a tightly-defined language specification and checks correctness at parse time, so errors that v1 might have surfaced at runtime now surface earlier and more bluntly. It also states that v2.0 produces Parquet artifacts that can be queried and joined, and that these encompass everything in the JSON artifacts, with manifest.json continuing to be produced for backwards compatibility.

That last clause is the practical hinge. Anything downstream of a dbt run that reads manifest.json keeps working, but the richer artifact is Parquet, and the revamped docs experience is built on it rather than on the JSON. Teams that parse artifacts themselves have a migration decision hiding inside a release note.

## Installing dbt Core v2.0 and running a first model

v2.0 ships as a single self-contained binary with no Python runtime and no dependency management, which the README lists as one of the big shifts from v1. The README does not print a curl or package-manager command; it points to the install page at docs.getdbt.com for dbt Core v2.0, so that page, not this article, is the place to get the exact download for your platform.

What the README does commit to is the support matrix, and it is narrow enough to check before you start. macOS and Linux are supported on both x86-64 and ARM. Windows is supported on x86-64 but marked as not yet supported on ARM. If you develop on a Windows ARM machine, v2.0 is not an option yet regardless of how the rest of your stack looks.

The older route still exists and is documented in the repository itself. The pyproject.toml declares requires-python >=3.9 and names the distribution dbt-core, which is the package that appears on PyPI:

```bash
pip install dbt-core
```

That command installs the Python implementation associated with the v1 line, not the Rust binary. If you are following a v1 tutorial, that is the correct package to install, and you should pair it with the adapter package for your warehouse rather than assuming dbt ships with connectivity built in. The README does not document adapter installation for v2.0 here, only that v2.0 and its drivers are compiled per operating system and architecture, so the driver and the core binary have to match.

Once installed and pointed at a warehouse profile, the workflow is unchanged from what the README describes: write a select statement as a model, and dbt materialises it. A model file is just SQL, and references between models are what build the graph. The README links to the docs for ref, documentation and testing rather than inlining the syntax, so treat the docs as the authority on the exact key names in dbt_project.yml and profiles.yml. Do not guess at config keys from v1 memory if you are on v2.0; the language specification is described as tightly defined, and parse-time enforcement means a wrong key fails early.

## The beta label is not decorative: what can break under you

The README is unusually direct about this. It states that dbt Core v2.0 is in beta and that behavior, APIs and on-disk formats may change before the stable release. On-disk formats is the phrase to sit with. If you build tooling that reads dbt artifacts, or if you archive artifacts for audit, a format change between beta releases is a change to files you may have already written.

The second limitation is the adapter surface. v2.0 and its drivers are compiled per operating system and architecture, which means the set of warehouses you can reach is the set of drivers that have been built for your platform. On v1, an adapter is a Python package and the platform question mostly disappears. On v2.0 it does not. The README's support table covers operating systems, not warehouses, and it does not enumerate which drivers exist at beta time, so that is a question to answer before you plan a migration rather than after.

The third is the language specification itself. Stricter parsing is presented as a feature, and for large projects it probably is, since catching an error at parse time beats catching it after a warehouse has spent twenty minutes on a bad run. But strictness is also a compatibility tax. Projects that accumulated loose Jinja, unusual macro patterns, or reliance on v1's more permissive resolution may not parse cleanly, and the README does not describe a compatibility mode or a migration tool. The repository does carry a .changes directory and a .changie.yaml, which suggests changelog entries are managed per change, so the CHANGELOG files are where to look for behaviour differences between beta releases. Neither CHANGELOG is summarised in the README.

Finally, the two status labels disagree. The README says beta; pyproject.toml says Alpha. When a project's own metadata is more conservative than its marketing page, the metadata is the safer planning assumption.

## dbt Core v2.0 against the Fusion distribution, and against v1 on 1.latest

The README frames the choice as two distributions of one framework. dbt Core is the Apache 2.0 baseline that you can read line by line. Fusion is a free local CLI that, in the README's words, can do more than dbt Core out of the box, with advanced features enabled over time. The README states that both share a single language specification, so business logic is portable in both directions.

That is a real architectural difference and not a branding one. Fusion extends dbt Core with additional SQL comprehension abilities, per the README, which means the comprehension layer is where the distributions diverge. If your reason for choosing dbt Core is licence review and code auditability, you are trading away whatever that comprehension layer does. If you are choosing Fusion for the extra capability, you are giving up the ability to read the whole thing, because some crates in the workspace are grouped under Source Available rather than the repository's Apache 2.0 licence.

The more consequential comparison for most teams is not Core against Fusion but v2.0 against v1. They are not the same program on two release channels. v1 is Python, installed from PyPI, and lives on the 1.latest branch. v2.0 is Rust, distributed as a binary, and lives on main. A team that runs pip install dbt-core today and a team that downloads the v2.0 binary are running different codebases with different artifact formats and different parsing rules. The README's promise of portability applies to business logic, that is, the SQL and the model definitions, not to the runtime, the install path, or the tooling around it.

## Maintenance, release cadence and what the Apache 2.0 licence does and does not cover

The repository is not archived, and the last push was on 2026-08-27. Releases in the recent window include v2.0.0-dev.30 on the same date as that push, plus v1.12.3 and v1.11.14 in the days before it. Two things follow. First, both lines are receiving releases, so moving to 1.latest is not a dead end. Second, the v2.0 line is still on dev-numbered releases, which is consistent with the beta warning rather than with a stable channel.

The upgrade cost differs sharply between the lines. On v1, upgrading means a new PyPI version and whatever adapter compatibility comes with it, and the release notes are the place to check. On v2.0, upgrading means replacing a binary, and because the README warns that on-disk formats may change, an upgrade can invalidate artifacts your tooling already consumed. Budget for that by pinning the binary version in CI the same way you would pin a package, and by checking the CHANGELOG files at the repository root before moving the pin.

On licensing, the repository is Apache-2.0 and the README states that dbt Core is licensed under the Apache License 2.0. That covers the repository as licensed. It does not automatically cover every crate: the Cargo workspace file groups a set of crates under a comment reading Source Available, which is a different category. If your adoption decision rests on reviewing every line under a permissive licence, read the licence headers of the specific crates you depend on rather than the repository-level LICENSE file alone. This is a description of what the files say, not legal advice, and a licence review is the right place to settle it.

## Conclusion

Adopt dbt Core v2.0 only if you can absorb beta churn: the README states that behavior, APIs and on-disk formats may change before the stable release, and the project's own pyproject.toml still classifies it as Alpha. Stay on the 1.latest branch if your project depends on Python-based adapters, custom Jinja macros that rely on v1 semantics, or anything that parses manifest.json downstream. Before committing, verify three things: that a driver exists for your warehouse on your OS and architecture (Windows ARM is listed as not yet supported), that your CI can consume Parquet artifacts in addition to the JSON ones, and that your models parse under the stricter v2 language specification. If any of those fail, the 1.latest branch is the correct target, not a compromise.

## FAQ

### What is dbt Core?

dbt Core is the baseline, Apache 2.0 licensed distribution of dbt. Analysts write select statements as models, and dbt turns them into tables and views in a data warehouse, managing relationships between models, generating documentation, and running tests.

### Is dbt Core still available?

Yes. The repository is not archived, and recent releases include v1.12.3 and v1.11.14 alongside v2.0.0-dev.30. The README notes that v1 development has moved to the 1.latest branch, while main hosts dbt Core v2.0 in beta.

### What are the key differences between dbt Core and dbt Cloud?

The README describes dbt Core as the baseline distribution and points to the dbt platform for an enhanced collaboration experience. It does not enumerate the feature differences, so the platform documentation is the place to compare them.

### How do I install dbt Core on Windows?

The README's support table lists Windows as supported on x86-64 and not yet supported on ARM. For v2.0 it points to the install page at docs.getdbt.com rather than giving a command, and the Python distribution is installable with pip install dbt-core.

### How do I install dbt Core?

For the v2.0 line, the README points to the install page for dbt Core v2.0, which ships as a single self-contained binary with no Python runtime. For the v1 line, the distribution is named dbt-core in pyproject.toml and requires Python 3.9 or later.

### What is the latest dbt Core version?

The most recent releases listed for the repository are v2.0.0-dev.30, v1.12.3 and v1.11.14. The v2.0 line is on dev-numbered releases and the README describes it as beta, so the highest number is not the stable channel.

## Sources

- [Official documentation](https://getdbt.com)
- [Official README](https://github.com/dbt-labs/dbt-core#readme)
- [Project repository](https://github.com/dbt-labs/dbt-core)
- [Release notes](https://github.com/dbt-labs/dbt-core/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dbt-labs-dbt-core