dbt turns SQL files into an ordered warehouse build
dbt lets an analyst write select statements as named models, then works out the order in which they must run. References between models become a dependency graph. Tests check assumptions about the resulting data, and generated documentation shows how those pieces connect. The useful shift is organizational as much as technical: warehouse changes become files that can be reviewed, versioned, rerun, and compared instead of a series of edits made by hand.
The codebase carrying that idea is large. Our checkout contained 3,926 files, roughly 724,213 source lines, and 38.4 MB before installation. GitHub identified Rust as the primary language on the current branch. That matters because many experienced dbt users still picture the Python engine and its adapter packages. The name stayed the same while the implementation, packaging, validation rules, and some licensing boundaries changed underneath it.
main is Rust v2, while Python v1 moved to 1.latest
The repository warning is unusually direct. Development of dbt v1 moved to the 1.latest branch, and main now holds a ground-up Rust rewrite. The README describes v2 as beta and says behavior, APIs, and on-disk formats may change. It also promises a self-contained binary, stricter parsing, Parquet project artifacts, continued JSON artifact output, and a rebuilt local documentation experience. Performance claims come from dbt Labs, not our run.
Our lab runner classified commit 1856183 as Python, installed 35 packages in 26 seconds, and recorded 37 MB on disk. That does not turn the current branch back into a Python project. The root still has a pyproject.toml, while contributors are instructed to install Rust and Nextest, run Cargo builds, use Clippy, and test against a real dbt project. Buyers need to distinguish packaging glue from the engine they will operate.
What happened when we ran it
Installation succeeded in the fresh Python 3.12 Debian container, and the recorded build step also succeeded. The test stage was skipped because the harness found no test script or target. Pip-audit found no known vulnerabilities in the 35 installed packages. This is a clean result for the dependency path the lab detected, but it does not cover a warehouse connection, project parsing, model execution, adapter behavior, or v1 compatibility.
The install took 26 seconds and the build took 2 seconds on 3 CPUs with 8 GB of RAM. Our scan counted 25 CI workflow files, no Dockerfile, and no root tests directory. The contribution guide separately names cargo nextest run, and the Rust crates include test code, so “skipped” describes our automation rather than the maintainers' full verification system. We did not substitute a made-up test count for a suite our harness never launched.
Apache 2.0 covers the engine, not every dbt feature
The source in this repository is Apache 2.0. The standard dbt distribution adds dbt-specific features under a product license, while the Apache-only package is installed separately as dbt-core. Official installation docs say the open runtime includes the project language, dependency graph semantics, and commands such as run, build, test, compile, and parse. That is enough to operate transformations, though it is not the entire desktop development experience.
The OSS package omits SQL comprehension and static analysis, language-server editor help, dbt lint, and VS Code extension integration. Those boundaries are more consequential than the 37 MB our install occupied. The standard v2 package can run without a paid plan, but some richer features require signing in with a free dbt platform account. A compliance review should therefore name the exact package and features being approved, instead of treating the GitHub license as a blanket answer.
Six documented adapters narrow the v2 migration
The v2 support page lists BigQuery, Databricks, Redshift, Snowflake, Apache Spark, and DuckDB. Several carry preview or beta labels, and authentication choices differ by warehouse. Existing projects must first run cleanly on the latest v1 with no deprecation errors. Packages also need a compatible require-dbt-version, while exact v1 log consumers and some materializations still face gaps. dbt v1 remains supported for projects that cannot move yet.
A 724,213-line codebase cannot make those compatibility decisions for your project. Open issue 15714 asks for SQL Server support. Issue 16331 reports a BigQuery relation-cache failure that can make incremental models run create or replace while the command exits successfully. Both are specific reasons to test adapter behavior and resulting SQL, not merely whether parsing finishes. Run v1 and v2 against isolated schemas, compare manifests, and inspect warehouse job history before promotion.
Same-day release activity meets a large bug queue
GitHub showed a September 16, 2026 push and a v2.0.4 release published that morning. The repository had 13,836 stars, 1,547 combined open issues and pull requests, and 1,276 open issues in the search result. New v2 reports were being filed and updated the same day. That is strong activity with a substantial triage surface, which fits a widely used engine in the middle of a rewrite better than either “abandoned” or “settled.”
The 25 workflow files and same-day release cadence show serious release machinery. Our missing test execution still leaves the adoption burden with the buyer. dbt v2 is worth testing for supported warehouses and projects that have already cleared v1 deprecations. Keep v1 available until the new engine reproduces the models, tests, hooks, artifacts, and incremental behavior that your production schedule depends on.