dbt Core v2 Rust Engine

dbt Core v2 dropped on June 1, 2026, the same day Fivetran and dbt Labs closed their all-stock merger.^[1] The v2 alpha is a complete Rust rewrite that parses a 10,000-model project up to 30x faster than v1.^[2] The two-engine era is over: the proprietary dbt Fusion engine and the open-source Python core now share a single Apache 2.0-licensed runtime.^[2] The combined company is approaching $600 million in annual recurring revenue, serves more than 100,000 data teams globally, and counts OpenAI, Zendesk, and HubSpot among its customers.^[1]

If you're running dbt in production, you have a concrete decision to make right now. Not "someday when v2 goes GA." Right now. Because the alpha already broke pip installs for anyone without version pins, and the adapter you depend on might not exist in v2 yet.

What the Fivetran dbt Merger Actually Closes

The deal was announced on October 13, 2025 as an all-stock exchange based on an agreed ratio tied to revenues and growth rates; specific financial terms were never disclosed.^[6] It closed 8 months later on June 1, 2026.^[1] George Fraser stays on as CEO; dbt Labs co-founder Tristan Handy became President.^[1]

The combined entity's $600M ARR and 100,000+ data team footprint make this the largest consolidation in the modern data stack to date.^[1]

The strategic logic is straightforward: Fivetran owns ingestion, dbt owns transformation, and together they cover the 2 biggest pieces of the ELT pipeline. If you've been running both tools separately (and most teams have), a single vendor now controls both halves of your data workflow. Whether that's a feature or a risk depends on how much you trust the Apache 2.0 licensing commitment to hold.

1 Engine, 1 License: The dbt Fusion Engine Goes Apache 2.0

Here's the licensing history in 30 seconds. dbt Fusion was announced on May 28, 2025 under the Elastic License 2.0 (ELv2): free to use, but not OSI-approved open source.^[3] That created an awkward split. The open-source Python core (Apache 2.0) was the "real" dbt for the community, while the fast Rust engine sat behind a proprietary license. Vendors building on dbt had to pick a lane.

The merger killed that split. As of June 1, 2026, the Rust runtime code that lived in the dbt-fusion repository under ELv2 has been moved into the dbt-core repository under Apache 2.0.^[2][11] 1 engine, 1 license, 1 codebase. Open-source users get the same high-performance Rust foundation that powered the proprietary Fusion product.^[2]

This matters because it removes the "free tier left behind" concern. Under the old split, you could reasonably worry that dbt Labs would pour engineering effort into Fusion and let the Python core stagnate. That concern is now structurally impossible; there's only 1 runtime to invest in.

The dbt Rust Engine: Where the 30x Comes From

The headline number is real, but the context matters. Parsing a 10,000-model project takes over 60 seconds in dbt Core v1. The Rust engine does it in under 600 milliseconds.^[7] At the extreme end, a 100,000-model project that took nearly 20 minutes in v1 parses in under 10 seconds in v2.^[7]

For projects in the 500-model range (where most production dbt deployments actually live), the improvement is still meaningful. dbt Core v1 takes 15 to 30 seconds to parse a 500-model project with intricate Jinja; Fusion completes the same workload in a fraction of that time.^[3]

Beyond parsing, full-project compilation is roughly 2x faster, with near-instant recompilation of single files in the VS Code extension.^[3][13] The Fusion engine also consolidates test queries and runs only models impacted by a change, delivering 30 percent or greater reductions in warehouse compute costs.^[15]

The 30x speedup applies to parsing and compilation on your local machine and in CI. It does not make your warehouse queries run 30x faster. The bottleneck shifts from "waiting for dbt to figure out what to run" to "waiting for the warehouse to actually run it." For large projects where CI parse times were eating 5+ minutes per commit, this shift is material.

I've been through 3 waves of "the tools are changing everything." The tools change every 18 months; the problems don't. But a 30x improvement in compile-time iteration speed genuinely changes how you develop. When dbt parse takes 60 seconds, you batch up changes and test them in chunks. When it takes 600 milliseconds, you validate after every edit. The workflow shift matters more than the benchmark.

Real-Time SQL Validation Without a Warehouse

This is the feature that will change daily habits for most data engineers. dbt Core v2 introduces native SQL comprehension through static analysis: dialect-aware syntax validation, column-level lineage, and dependency checking, all running locally without a warehouse connection.^[9]

In practice, the dbt VS Code extension now surfaces inline syntax and column-name errors as you type.^[10] The built-in SQL linter runs roughly 50x faster than single-threaded SQLFluff.^[14] And v2's strict mode validates the entire project before any execution, catching errors that v1 would only surface at runtime.^[9]

If you've ever shipped a dbt model with a typo in a column reference and only found out when the warehouse threw an error 4 minutes into a CI run, this is directly for you. The feedback loop collapses from minutes to milliseconds. Unit test parent column discovery no longer requires warehouse round-trips; column types and names are inferred from static analysis.^[2]

For teams practicing dbt at scale, this is the single biggest quality-of-life improvement in v2. The 30x parsing speed is impressive on paper; the real-time validation is what you'll actually feel every day.

What Breaks in the dbt Core v2 Alpha

Here's the part that should have your attention right now.

On June 1, when dbt-core v2.0.0-alpha.1 hit PyPI, any pip install of a v1 adapter without an explicit upper-bound version pin automatically resolved to the alpha Rust engine.^[8] The Python adapter code is incompatible with Fusion, so dbt run and dbt parse fail immediately. The root cause: PEP 440 treats a lower bound like dbt-core>=1.10.0rc0 as pre-release eligible, making pip resolve to v2.0.0-alpha.1 as the highest available version.^[8]

I've debugged enough broken CI pipelines at 2am to know that "it'll probably be fine without version pins" is how you end up explaining to your team lead why the nightly run hasn't completed since Tuesday. Pin it now:

Beyond the pip resolution issue, the breaking changes in v2 are real and extensive:

• All deprecated functionality removed. Every deprecation warning introduced through dbt Core v1.10 becomes a hard error in v2. Behavior change flags that let you opt out in v1 are gone entirely.^[4]
• CLI flag rename. The --models / --model / -m flags are removed. dbt raises an error if you use them. Replacement: --select / -s.^[4]
• Adapter rewrite required. v1 adapters are standalone Python packages. v2 adapters are written in Rust, live inside the dbt-core monorepo, and connect via ADBC (Arrow Database Connectivity) drivers instead of Python-based connectors.^[5]
• Third-party package risk. dbt_utils, audit_helper, dbt_external_tables, and dbt_project_evaluator are v2-ready. External packages published outside dbt Labs may use outdated code that fails to parse.^[4]
• Manifest incompatibility. v2 can read v1 manifests; v1 cannot read v2 manifests. Your rollback plan needs to account for this asymmetry.^[4]

Current adapter status as of mid-2026: Snowflake, BigQuery, Databricks, and Redshift are in Preview. Spark and DuckDB are in Beta. PostgreSQL, MySQL, and Oracle are not yet ready.^[5] If you're running Trino, Athena, or any community-maintained adapter, you're waiting.

Alpha Now or Wait for GA: A Data Engineer's Decision Framework

dbt Labs is explicit: target GA for production.^[2] The alpha is for testing, not for your 2am pager. But "wait for GA" doesn't mean "do nothing." The migration has real prep work that starts now.

The recommended path: upgrade to dbt v1.12 first, then run dbt parse --use-v2-parser to validate that your project parses cleanly under v2 logic.^[4] v1.12 already enforces most of the behavior changes required in v2, making it the safe preparation checkpoint.

Here's how to think about your timeline:

• If you're on Snowflake, BigQuery, Databricks, or Redshift: start staging now. Your adapter is in Preview. Run the v2 parser test, resolve deprecation warnings, audit third-party packages. You can be ready for GA when it ships.
• If you're on Postgres, Spark, DuckDB, or a community adapter: upgrade to v1.12 and resolve all deprecation warnings. Monitor adapter status. You can't move to v2 until your adapter lands, but you can eliminate every other blocker in the meantime.
• If you're still on v1.3 through v1.7: move to v1.12 before January 31, 2027. Those versions will be deprecated on that date and removed from dbt platform availability.^[12] This is non-optional regardless of your v2 plans.

The dbt-autofix package and an agent skill for version upgrades can automate resolution of many compatibility issues.^[4] Use them. Manually resolving 200 deprecation warnings across a large project is exactly the kind of toil that eats a sprint and produces zero business value.

What This Means for Data Engineering Interviews in 2026

The Fivetran dbt merger and the v2 launch are already showing up in interview loops. If you're grinding through data engineering interview prep right now, here's what's shifting.

dbt knowledge is no longer optional for senior and staff roles. With 100,000+ data teams on the combined platform,^[1] interviewers assume familiarity. The questions are getting specific: not "have you used dbt?" but "how would you handle the v2 migration for a project with 3,000 models and a custom Postgres adapter?" If you haven't thought through that answer, start with the dbt interview questions on DataDriven and layer in v2 specifics.

The merger also blurs the line between ingestion and transformation in interview discussions. Candidates who can talk about ELT pipeline architecture as a unified concern rather than 2 separate tool conversations will stand out. Understanding that Fivetran handles ingestion metadata that flows into dbt's lineage graph signals architectural thinking at the platform level.

And v2's stricter parser changes the "correctness" bar. When YAML typos like "desciptin" instead of "description" are now caught at parse time rather than silently ignored,^[16] interviewers will probe whether your testing and CI/CD strategy catches configuration drift before it ships. This connects directly to idempotent pipeline design: building systems that fail loudly and recover cleanly.

The practical advice: spin up a personal dbt project, run it on v1.12, test --use-v2-parser, and be ready to talk about what broke and how you fixed it. That's a 3-hour investment that gives you a real war story for interview conversations. Courses will teach you theory you already know; what you need is reps on the stuff that's actually changing.

If you're deep in prep right now, DataDriven's practice problems cover the SQL and data modeling fundamentals that stay constant regardless of which dbt version you're running. Concepts transfer across tools; tool knowledge doesn't transfer across concepts. Learn the v2 specifics because they're immediately relevant, but don't lose sight of the fundamentals that got you here.

References

1. Fivetran, "Fivetran and dbt Labs Complete Merger to Create the Data Infrastructure for Trusted AI Agents," June 1, 2026. fivetran.com
2. dbt Labs, "dbt Core v2 is here: still open source, now rebuilt for what's next," June 1, 2026. docs.getdbt.com
3. dbt Labs, "Meet the dbt Fusion Engine: the new Rust-based, industrial-grade engine for dbt," May 28, 2025. docs.getdbt.com
4. dbt Labs, "Upgrading to v2," dbt Developer Hub. docs.getdbt.com
5. dbt Labs, "Contribute a dbt Core v2.0 adapter," dbt Developer Hub. docs.getdbt.com
6. Fivetran, "Fivetran and dbt Labs Unite to Set the Standard for Open Data Infrastructure," October 13, 2025. fivetran.com
7. dbt Labs, "Parser, Better, Faster, Stronger: A peek at the new dbt engine," dbt Developer Blog. docs.getdbt.com
8. dbt-labs/dbt-adapters, "Adapter packages missing dbt-core<2.0 upper bound," GitHub Issue #2010. github.com
9. dbt Labs, "A new concept: static analysis," dbt Developer Hub. docs.getdbt.com
10. dbt Labs, "dbt extension features," dbt Developer Hub. docs.getdbt.com
11. dbt Labs, "dbt Licensing FAQ." getdbt.com
12. endoflife.date, "dbt Core." endoflife.date
13. dbt Labs, "Rebuilding dbt Core in the open: Faster runtime, adapters, and docs v2," dbt Summit 2026. getdbt.com
14. dbt Labs, "Accelerate data workflows with the dbt Fusion engine." getdbt.com
15. dbt Labs, "dbt Fusion Report: Analytics and AI Foundation." getdbt.com
16. dbt Labs, "About dbt versions," dbt Developer Hub. docs.getdbt.com