Choose the implementation before judging setup
A successful harness step is not enough to establish that dbt is ready to run your project. Our recorded setup exposes that distinction: the install summary reports success while its captured output contains packaging errors.
The underlying product serves a clear purpose. dbt turns select statements into warehouse tables and views, manages relationships between models, and supports testing those transformations. It is worth evaluating when a team needs to maintain shared SQL models.
The repository README places Python v1 development on 1.latest and the Rust v2 implementation on main. Its supplied text does not label v2 beta or state that its interfaces and disk formats may change. This review therefore makes no such claim.
What our recorded run establishes
Our run took place on October 4, 2026 at commit 7bbd974389dbd08da3ece92396ecdd0c8f99719c, dated October 2, 2026. The detector found Python and Rust and selected Python as primary. The configured sandbox had 3 CPUs and 8 GB of memory, using ghcr.io/astral-sh/uv:python3.12-bookworm; the install output identifies Python 3.12.12.
The install step lasted 20 seconds and received a successful harness status. Its captured output nevertheless reports failed editable and wheel build preparation through setuptools, including a multiple-top-level-packages error. This record does not establish that the dbt CLI was installed. It also does not establish that the documented Rust binary installation path is broken: the recorded attempt used Python packaging against this checkout.
The dependency summary records 35 packages and 37 MB. Those figures do not demonstrate successful installation of the product. The build step returned exit 0 in approximately 3 seconds, but the supplied record contains neither its command nor output proving Rust compilation. No installed-binary check is recorded.
Tests were skipped with reason no script. That is a limitation of this run, not an upstream test failure or proof that dbt lacks tests. No warehouse workload, SQL correctness check, adapter comparison, or performance benchmark is recorded.
The checkout summary records 3,979 files, 739,739 lines of source, 42.9 MB, and 25 CI workflow files. The scanner did not flag a Dockerfile, Compose configuration, or top-level tests directory. These are scanner observations for this commit, not an exhaustive inventory of supported development workflows.
The pip-audit summary records zero advisories, but audit coverage is unknown. Neither the dependency count nor the successful step status establishes how much software was inspected.
What the README promises
The README describes v2 as a self-contained binary requiring no Python runtime or dependency management. It also claims faster parsing and compilation and describes Parquet artifacts alongside continued JSON artifacts. These are project claims; our run did not verify binary installation, speed, or artifact compatibility.
Its support table lists Linux and macOS on x86-64 and ARM, plus Windows on x86-64. Windows on ARM is marked not yet supported. The README distinguishes Apache-2.0 repository source from a dbt distribution with customizations under a dbt product license. Check which source or distribution you intend to use before making licensing or deployment decisions.
Check hook behavior against the exact parser version
Issue 16310 concerns the --use-v2-parser path used with Python dbt Core. The original report names dbt 1.12.4, dbt-core-experimental-parser 2.0.1, dbt-adapters 1.24.5, and dbt-duckdb 1.11.0. Its reporter described missing start and end hooks despite a successful command exit. This was someone else's reproduction, not our test.
The issue was closed as completed on September 16, 2026, with a referenced fix. An October 15 comment subsequently reported that the fix had not reached a 2.0.x stable release, including parser 2.0.8, while a development version emitted the expected hook tags. That comment is a reported release-specific limitation, not proof that every v2 execution path has the defect. Closure alone does not establish that a particular installed package contains the fix.
For a migration trial, record the engine, parser, adapter, and package versions. Check the executable first, then compare representative models, hook execution, and any artifacts your tooling consumes. Our run leaves those checks open.
When to consider another tool
SQLMesh's README documents SQL and Python transformations, virtual data environments, and a Plan / Apply workflow for reviewing change impact. Evaluate it when those deployment controls drive your choice. We did not measure its performance or compare its compatibility with dbt.
Mage's README describes local Python, SQL, and R pipelines, connectors, scheduling, and a notebook-style interface. Evaluate it when broader pipeline authoring belongs in the same workspace. It also documents dbt support, making it a possible companion to dbt rather than a mandatory replacement.
How to read the scores
These are editorial evidence ratings, not benchmark results. On the five-point scale, 1 means substantial unresolved obstacles, 2 means partial evidence with major verification gaps, 3 means a documented evaluation path with important checks still open, 4 requires strong evidence in the relevant area, and 5 requires broad corroboration. Unknown adoption and compatibility do not earn high ratings.
Setup receives 2 because installation remains unverified. Documentation receives 3 because the supplied README explains the branch split, distribution, and platform support, while the linked installation instructions were not supplied. Community receives 2 because discussion and contribution channels are documented, but adoption and response quality were not measured. Maturity receives 2 because the implementation split and parser reports leave release-specific compatibility unresolved in this evaluation.