dbt Core v2.0 is Here, and the Real Story isn't the One in the Headline

dbt Core v2.0 was announced today. The headline is a faster, Rust-powered engine. The quieter story matters more.

For most of dbt's life, "the open-source dbt" and "the dbt everyone actually uses" were the same artifact. As of dbt 2.0, it’s a little more complicated.

Credit where it's due: dbt 2.0 is impressive. The high-performance Rust runtime is now open source under Apache 2.0. dbt Labs opened up a large amount of previously proprietary IP, and the new Parquet artifacts and tightly-defined language spec are a genuine leap. As maintainers of the dbt_artifacts package, we're especially keen on both: a queryable, scalable artifact format plus a stable spec to build against should make ecosystem integrations far more maintainable. The bet on Apache Arrow Database Connectivity (ADBC) and the Arrow ecosystem is a smart nod to interoperability, too. Our very own David Gelman, PhD recently explored this topic in depth in our recent blog, The Right Tool for the Right Job: What Open Data Infrastructure Really Means, which examines how open standards and interoperable architectures are shaping the next era of data.

Importantly, if you read the announcement closely, the positioning is unmistakable: dbt Labs now recommends Fusion, not Core, for nearly everyone. Core has been reframed as a niche option for the small set of teams that require pure open source or build directly on top of the framework. Fusion, the default they're steering you toward, is free to install but open-core: it carries proprietary code and a freemium upgrade path.

This isn't a knock on dbt; the engineering is excellent. It's a real shift and necessary to explicitly name. The open question is what this means for dbt's identity as an open-source-first project when the tool you're told to reach for is no longer the fully-open one.

There's a practical wrinkle, too. The Rust binary moves away from the Python virtual-environment pattern we've relied on for years. For anyone managing many environments at once, that's a prompt to rethink how implementations are structured, and we expect containerization to carry more of that load.

And all of this lands as the first major release under the combined Fivetran + dbt Labs. We'll dig into that separately.

If you're weighing agent-readiness (Parquet artifacts your tools can query, a spec your tooling can build against) or simply whether your project survives the jump, start simple: run dbt parse --use-v2-parser and see where you stand.

For everything dbt parse --use-v2-parser won't catch (behavior changes, package compatibility, what agent-readiness actually means for your project, and sequencing a migration across environments), that's the work we do. It's exactly what our Fusion Assessment is built for.