dbt Core 2.0 RC2: Fix These 4 Issues Before GA Ships

dbt Core 2.0 RC2 dropped September 8. GA is weeks away. If your data pipelines read from manifest.json, use --models flags in CI, or have YAML configs with silently ignored typos, you have a problem — and you have a narrow window to fix it on your terms before v2’s strict parser does it for you on its terms.

Run This Command Before You Do Anything Else

The fastest way to know your migration readiness is also the only reliable one:

pip install "dbt-core==1.12.0"
dbt parse --use-v2-parser

Every warning this surfaces becomes a hard parse failure in dbt Core 2.0. Not a deprecation. Not a warning. A failure. Run it against your production project now — not after GA ships.

The most common findings teams report: YAML keys with typos that v1 silently accepted, CLI flags that no longer exist, and model configs that don’t match the new strict specification. None of these show up as runtime errors in v1. All of them will kill your dbt build in v2.

Your manifest.json Has an Expiration Date

dbt v1 produces a manifest.json that can run 70 MB or more on large projects. Tools like DataHub, Atlan, and OpenMetadata ingest it. CI scripts diff it to catch breaking schema changes. Custom lineage parsers deserialize the entire file to answer a single question about a single model.

dbt v2 replaces this with Parquet artifacts. Same information, radically different format: a 70 MB manifest compresses to roughly 6 MB. More importantly, you can query it directly via DuckDB without deserializing the whole thing. New parse-safe views — dbt.models, dbt.graph_nodes, dbt.seeds — let you query metadata without a full project compile.

The JSON artifacts stay available during the transition window, so nothing breaks the day you upgrade. The problem is that “transition window” has an end date. If your catalog connectors, CI tooling, or custom integrations haven’t migrated to Parquet by then, that end date becomes your outage.

Start auditing your downstream manifest consumers now. If you use DataHub, Atlan, or OpenMetadata, check their v2 connector roadmaps. If you have homegrown scripts parsing manifest.json, plan the rewrite. The new Parquet-native approach is genuinely better — column-level lineage is now tracked at Jinja render time instead of reconstructed after the fact — but “better” doesn’t mean “automatic.”

The Strict Spec Will Surface Silent Bugs You Didn’t Know You Had

dbt v1 was lenient with YAML configs. Misspell a property key and v1 shrugged and moved on. This made initial project setup forgiving but created a class of configuration bugs that never surfaced as errors — they just silently did nothing.

dbt v2 introduces a codified language specification. Misspell a key in your YAML and the parser fails. This is the right behavior — it turns the dbt manifest into a reliable metadata contract — but it means teams inheriting old projects will discover configuration debt they didn’t know they were carrying.

The migration command above catches these. Run it. Fix the warnings. This is not optional if you want a clean GA upgrade.

Update These CLI Flags in Your CI/CD Now

Two commonly used flags are gone in v2:

• --models and its shorthand -m — replace with --select
• --partial-parse — removed with no direct replacement

Search your CI pipelines, Makefiles, dbt Cloud job definitions, and any shell scripts that invoke dbt. Replace every instance before GA ships. This takes 20 minutes and prevents a guaranteed production failure.

What RC2 Actually Added

RC2 (September 8) moved from RC1 (September 2) with six days of focused fixes and adapter work:

• Exasol adapter Phase 1 — connection/auth, metadata, full macro bundle including materializations and model contracts
• Databricks query tags — automatic dbt metadata injected at profile and model level
• Databricks serverless — Fusion now accepts environment_key and environment_dependencies for Python models on serverless compute
• ClickHouse improvements — definer, sql_security, inserts_only configs; s3() table function support
• Contract enforcement fix — model and column constraints now apply only when contract.enforced: true, fixing an RC1 regression

If RC1 broke your Databricks queries or your ClickHouse materializations, RC2 addresses both. The contract enforcement fix matters for any team using model contracts — it was incorrectly enforcing constraints regardless of the enforced flag in RC1.

Core or Fusion?

dbt v2 ships as two distributions. dbt Core (Apache 2.0) is the pure open-source option. dbt Fusion is a free binary distribution that adds SQL linting and column-level lineage on top of the same Rust runtime.

The practical answer: if your organization requires pure Apache 2.0 licensing for legal or compliance reasons, use Core. For everyone else, Fusion is worth evaluating — the SQL linter and native column lineage are useful, and it costs nothing to install. The commercial edge is dbt State (metered at $0.094 per daily unique reuse), which you can skip entirely if your workflow doesn’t need it.

The Timeline

RC2 is not production-ready. dbt Labs hasn’t announced a GA date, but RC2 following RC1 by six days suggests rapid iteration. Expect GA in weeks, not months.

Start with dbt parse --use-v2-parser on your v1.12 project. Fix the warnings. Audit your downstream manifest consumers. Update your CI flags. By the time GA lands, the upgrade should be a one-line version bump, not a three-day fire drill.