dbt Fusion engine: a Rust rewrite of the dbt Core execution engine, still Beta

A ground up rewrite of the execution engine, not a new authoring layer

The dbt Fusion engine is the part of dbt that turns your project files into warehouse queries. dbt Core implements that part in Python; Fusion implements it in Rust and compiles to a single application binary. The README describes it as a ground up, first principles rewrite that stays interoperable with the standard dbt authoring layer, so the YAML you already write is meant to keep working. The stated goals are speed, correctness and a native understanding of SQL across multiple warehouse dialects. This is an engine swap, not a new way of authoring, which matters because the surrounding tooling, the adapters and the ecosystem around dbt all assume the authoring contract stays put. The README also says the engine is being released to this repository incrementally, and that until a specific note is removed the repository holds only a subset of the crates that make the engine work.

Stricter validation is the behavioural difference from dbt Core

The FAQ lists what stays the same: the YAML authoring format including profiles, configuration, seeds, data tests and unit tests, the materialization libraries, and dbt's library management system, with the note that dbt deps are installed automatically. Where the two engines diverge is enforcement. Fusion enforces some ambiguous areas of the authoring spec more strictly than dbt Core does, and the README gives a concrete example: dbt Core does not proactively validate most YAML configurations, while Fusion does. In practice that means a project that ran clean on dbt Core can fail on Fusion with configuration errors that were previously ignored. The README points at a mitigation, the dbt Autofix tool, which can repair many of these discrepancies automatically. Whether you like that trade depends on your position: stricter parsing catches real mistakes, and it also turns previously silent configuration debt into build failures on the day you switch engines.

ADBC drivers, a language server and multi-dialect SQL are the new pieces

Beyond matching dbt Core behaviour, Fusion adds capabilities that dbt Core does not ship. The first is a set of Arrow Database Connector drivers for faster data transfers and unified connection handling, wrapped by the dbt-xdbc crate as a Rust wrapper over ADBC and ODBC. The second is a language server with a VS Code extension, compatible with Cursor, for authoring feedback inside an editor. The third is multi-dialect SQL compilation, validation and static analysis, backed by ANTLR grammars per warehouse. Installation is deliberately dependency free. The README states the engine can be installed on a local machine, in a docker container or on a machine in the cloud, and that the only libraries it loads are the corresponding database drivers. There is also a Rust port of the Python agate library in the crate list, which is the kind of detail that only matters if you are porting custom materializations.

One curl command, the VS Code extension, or a container

The README recommends the precompiled binary over building from source, and gives a single command that installs the Fusion CLI. The install script is fetched over HTTPS from dbt's public CDN and piped to a shell, so read it before running it if that is not your habit; the documented alternative is the VS Code extension, which installs both the dbt fusion CLI and the language server on your system. A third option is a docker container, and the README also mentions installing on a machine in the cloud.

curl -fsSL https://public.cdn.getdbt.com/fs/install/install.sh | sh -s -- --update

Support is per operating system and CPU architecture, because Fusion and its drivers are compiled for each combination independently. macOS and Linux are supported on both X86-64 and ARM today; Windows is supported on X86-64, while Windows on ARM is marked unsupported today. That last cell is the one to check if your team develops on Surface hardware. The pyproject.toml at the repository root describes the CLI distribution, and its classifiers mark the project as Development Status :: 3 - Alpha.

The repository is a partial release, and the SQL grammars are still open

The checked list of released components tells you what exists today: dbt-jinja, a Rust extension of mini-jinja for dbt's Jinja functions, dbt-parser for dbt projects, dbt-schemas with machine generated JSON schemas for properties and configurations, dbt-adapter with snowflake, databricks, bigquery and redshift, dbt-xdbc, dbt-auth and dbt-agate. Two entries remain unchecked. dbt-sql, the ANTLR grammars and generated parsers for each of the four dialects, is still open, and so is the full release of the engine itself, which the README describes as source-available. The timeline gives the order things shipped in: the parser, schemas, dbt-jinja and the Snowflake ADBC driver on 2025-05-28, the Databricks adapter on 2025-06-09, BigQuery on 2025-06-30, Redshift on 2025-07-31, and the adapter components published under the Apache 2.0 licence on 2025-09-30. The ANTLR grammars row has no date and reads TBD.

Beta status, missing functionality and an issue tracker that moved away

The README carries a prominent Beta notice and states that bugs and missing functionality compared to dbt Core will be resolved in the leadup to a final release, pointing at a post on the path to general availability. That is the honest framing for evaluating the risk. The repository also has no GitHub releases, so there is no tag to pin and no changelog to diff, only a CHANGELOG.md in the repository root and a changie configuration for unreleased changes. The last push was on 2026-06-26, so the code moves but the release surface does not. Separately, issue tracking has moved: new bugs for the Fusion engine are filed in dbt-labs/dbt-core alongside the rest of dbt, and existing issues were transferred with old links redirecting automatically. If you evaluate tools by how quickly a maintainer answers an issue, that routing is a real signal.

Licensing is mixed: source-available engine, Apache 2.0 adapters

The repository ships a LICENSES.md file rather than a single recognisable licence, and the GitHub licence field is not populated, so you have to read that file to know what you are agreeing to. The clues in the README point to a split: the adapter components were published under the Apache 2.0 licence on 2025-09-30, while the full release of the Fusion engine is described as source-available, which is a different arrangement and usually a more restrictive one for commercial use. That distinction decides who can ship the engine inside a commercial product and who cannot, so treat LICENSES.md as a required read rather than a formality. This is a description of how the project distributes its code, not legal advice, and the terms you accept are the ones written in those files.

Editorial conclusion

dbt Fusion makes sense for a team that wants to try a faster engine on a subset of its models, or that needs the language server and ADBC drivers today, and that accepts rewriting its expectations about validation errors. It does not make sense as a drop-in replacement for a production dbt Core deployment yet, because the README lists missing functionality relative to dbt Core and the ANTLR SQL grammars are still marked as to be determined. Before running any production workload on it, read LICENSES.md, since the engine is described as source-available while the adapter components moved to Apache 2.0, and file issues in dbt-labs/dbt-core because this repository no longer tracks them.

Frequently asked questions

Official sources

1. dbt-labs/dbt-fusion on GitHub
2. Issues
3. README