TL;DR. dbt Core hit its first 2.0 release candidate on September 2, 2026. The headline is the engine: the Rust core that powers dbt Fusion, now the Apache 2.0 foundation of open-source dbt. The change with the longest reach is quieter and sits in the artifact layer. Parquet metadata artifacts that downstream tools query instead of parse, a codified language spec that stops silently ignoring configuration, and reference provenance recorded while templates render. manifest.json became the metadata backbone of the analytics stack by accident. 2.0 is the first release that treats that role as a contract, and every catalog, lineage parser, and CI check built on the old blob inherits the change.
dbt Labs announced v2 in June 2026 with an unusually blunt framing: after a year of maintaining the Python engine and the Rust-based Fusion engine in parallel, there would now be "one engine, under the Apache 2.0 license, indivisible, with faster parsing and modern interfaces for all." The Fusion codebase, first released in May 2025, becomes the foundation of open-source dbt Core. The alpha landed in June, a second beta on August 18, and the release candidate on September 2. Two distributions come out the other side: dbt-core, Apache 2.0, adapters bundled into the monorepo and rebuilt on ADBC and the Arrow ecosystem, and a proprietary Fusion distribution layering commercial features on the same engine.
Most coverage of 2.0 has read it as a performance story, and the parse-time numbers on large projects support that reading. But dbt's real surface area in a data platform was never the CLI. It is the pile of JSON the CLI leaves behind.
The interchange format nobody designed
Every dbt invocation writes artifacts: manifest.json with the full graph of models, sources, tests, and their compiled SQL, catalog.json with warehouse schema detail, run_results.json with execution outcomes. Those files were built as internal state for dbt's own docs site and state comparison. Then the rest of the ecosystem discovered they were the cheapest complete description of a warehouse's transformation layer, and quietly standardized on them.
Point a catalog at a dbt project and what actually happens is manifest ingestion. DataHub's dbt source reads manifest.json and catalog.json. OpenMetadata's dbt workflow does the same, as do Atlan's, and the observability vendors', and a long tail of homegrown CI scripts that diff manifests to find breaking changes. When OpenMetadata rebranded the catalog as a context layer, the dbt integration came along as a first-class source, because for most analytics estates the manifest is where the semantics live: model descriptions, column docs, tests, ownership, the dependency graph. The file format nobody designed became the interchange layer everybody depends on.
It scaled badly. In the dbt-docs rebuild discussion, the maintainers describe the old model plainly: docs worked by loading the entire manifest.json and catalog.json into the browser, and on real deployments a manifest "could be 50 MB, let alone a gigabyte." Every consumer paid the same tax. A catalog re-ingesting a nightly manifest parses the whole graph to learn that three models changed. A CI bot answering one question about one model deserializes fifty megabytes to ask it.
The 2.0 artifact layer inverts the direction of the contract: consumers pull what they need instead of receiving everything.
Metadata you query instead of parse
2.0's answer is Parquet metadata artifacts, described in the announcement as "built for speed & scale, powering new dbt-docs." The artifacts cover everything the JSON artifacts contain, and the JSON continues to be produced for backwards compatibility, so nothing breaks on upgrade day. What changes is what a well-built consumer can now do: the metadata is, in the maintainers' words, "scalable, joinable, and analyzable, and the UI can query only what it needs."
The new docs experience is the proof of concept. Instead of shipping the whole manifest to the browser, docs v2 lazy-loads the Parquet artifacts alongside DuckDB WASM and runs queries client-side, which is how it supports column-level lineage and impact analysis on projects where v1 docs simply stopped working. One implementation note in the discussion reports a 70 MB manifest compressing to roughly 6 MB. The choice of query engine is its own signal: DuckDB's embeddable analytics is becoming default plumbing for exactly this kind of metadata workload, which is part of why AWS went to the length of acquiring the team behind it.
For catalog and lineage vendors the implication is direct. An ingestion job that today deserializes the world can become a set of queries: which nodes changed since the last sync, which columns feed this model, which tests cover that source. Selective reads against columnar artifacts are a different cost class from whole-file parses, and the first catalog to exploit that gets incremental dbt sync more or less for free.
A spec that stops ignoring your configuration
The second change reads as developer ergonomics and is really a semantic one. The v1 parser was tolerant by design: configuration it did not recognize was accepted and silently ignored. The 2.0 engine ships what the announcement calls a strict codified language spec, with "deprecation warnings to help you get your project up to the new stricter spec - no more configs being silently ignored." The release candidate extends the same discipline into the graph itself, with parse-safe node views that prevent compile-only columns from leaking into parse-time results.
Silently ignored configuration is not a papercut. It is metadata that lies. A config block that a human wrote, a reviewer approved, and the engine never honored still ends up serialized into the manifest, where every downstream consumer reads it as a statement about behavior. A catalog that ingests v1 manifests inherits v1's tolerance without knowing it. Under the stricter spec, what lands in the artifact is what the engine actually enforced, which is the property the semantic-layer standardization fights keep circling: a definition is only worth exchanging if every engine that reads it means the same thing by it.
Lineage recorded at render time, not reconstructed after
The release candidate's most underrated line item is reference provenance: the engine now tracks ref(), source(), and this calls during Jinja rendering, initially to power lint rules. That sounds like tooling plumbing until you consider how the entire ecosystem computes column-level lineage today: after the fact, by running SQL parsers over dbt's compiled output and reverse-engineering which columns feed which. It works until it meets a dialect quirk, a macro-generated expression, or a parser version skew, and every vendor maintains that reconstruction machinery independently.
Provenance recorded at the moment a reference resolves is a different kind of fact. The engine does not have to guess what a model depends on; it watched the dependency get rendered. As that data flows into the artifacts, the downstream lineage industry shifts from reconstruction to verification: parse if you must, but check it against what the engine recorded. We made a version of this argument about propagated metadata in catalogs: metadata is trustworthy in proportion to how close to the event it was captured. Render time is as close as transformation lineage gets.
The fine print worth reading twice
Two smaller items in the release candidate deserve more attention than their changelog placement suggests. The first is a security fix: package tarball extraction now skips symlink, hard link, and device entries instead of extracting them as-is. dbt packages are a supply chain, resolved and extracted in CI environments that hold warehouse credentials, and this class of archive-extraction hole is exactly how a small parsing gap becomes credential reach. The fix is unglamorous and worth having.
The second is posture. dbt Labs states Core v1 "is not going away tomorrow, or any time soon," and v1.12 carries an opt-in --use-v2-parser flag so projects can burn down deprecation warnings before migrating. Read that as the migration actually being two migrations. Your project migrates when you move engines. Your metadata consumers migrate when they start reading Parquet instead of JSON, and nothing forces the two to happen together. The JSON compatibility window is what makes the transition survivable, and it is also a period in which the same project emits two representations of its own metadata, one of which will eventually stop being the one the tooling optimizes for. Teams that treat artifacts as an API, and there are more of them than dbt Labs probably knows, should be reading the artifact schemas now, not at GA.
Where Datapace fits
A transformation engine writing its own lineage down at render time is the artifact layer catching up to a principle Datapace is built around: context should be captured where it is produced, with its provenance attached, rather than reconstructed downstream by whoever needs it. Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. dbt's artifacts are one of the richest context sources that layer can draw on, and 2.0 turning them from a blob into a queryable surface is the difference between context an agent can cite and context a pipeline once summarized. If your catalog, your CI, or your agents are built on parsing manifest.json, book a call.
Sources
- dbt Labs, dbt-core v2.0.0-rc.1 release notes, September 2, 2026 (reference provenance tracking, parse-safe views, tarball extraction fix, adapter changes).
- dbt Labs, Announcing dbt Core v2, June 2026 roadmap document (one engine under Apache 2.0, strict language spec, Parquet artifacts, v1 support posture, --use-v2-parser).
- dbt Labs, We are re-building dbt-docs for speed & scale, dbt-core discussion #13080 (manifest sizes, DuckDB WASM architecture, lazy-loaded Parquet artifacts, column-level lineage).
- dbt Labs, dbt Core v2 is here: still open source, now rebuilt for what's next, dbt Developer Blog (two distributions, ADBC and Arrow adapter model, JSON artifacts retained for backwards compatibility).
- dbt Labs, dbt-core releases index (v2.0.0-beta.2, August 18, 2026; v1.12.3, August 20, 2026).