Fivetran and dbt Merged. Here Is What Data Engineers Get.

I've been through 3 mergers as a practitioner on the receiving end. Every time, the press release says "nothing changes for customers." Every time, something changes for customers.

On June 1, 2026, Fivetran and dbt Labs completed their all-stock merger, combining the dominant ingestion platform and the dominant transformation framework under one roof. The same day, dbt Core v2.0 shipped in alpha. The combined company serves more than 100,000 data teams and approaches $600 million in ARR.

One company now owns both layers of the modern data stack that most of you depend on. Let's talk about what you actually get.

What the Merger Means for Data Engineering Teams

George Fraser stays CEO. Tristan Handy becomes President. The deal is all-stock, no cash component disclosed. The combined entity counts OpenAI, Zendesk, Coupa, and HubSpot among its named customers.

Here's the context most coverage glosses over. Fivetran raised $565M at a $5.6B valuation in September 2021. dbt Labs raised $222M at a $4.2B valuation in February 2022. Both valuations were peak-ZIRP numbers. An all-stock merger in 2026 means those numbers got renegotiated by reality.

The strategic logic is straightforward: 80 to 90% of Fivetran's customer base already runs dbt. As Datacoves noted, the architectural lock-in was already present; the commercial incentive to make the pair inseparable is now explicit. Fivetran's recent pricing moves reinforce the skepticism. Starting January 2026, Fivetran shifted to per-connection billing with $5 minimums and began counting deletes toward MAR, bumping typical small-team costs from roughly $500/month to $1,200 to $1,800. That history makes the "we'll keep dbt Core open" pledge read differently than it would from a vendor with no recent price shock.

dbt's strength before this deal was tool-agnosticism. You could pair it with Fivetran, Airbyte, Stitch, or a pile of custom loaders. That neutrality is now a question mark. Not because anyone announced a restriction, but because the incentive structure shifted overnight.

dbt Core v2.0: The Rust Rewrite

The headline feature of v2.0 is the Rust-based Fusion engine, replacing the Python runtime. dbt Labs claims up to 30x faster parsing on projects with 10,000+ models and 2x faster full-project compilation overall. A 5,000-model project reportedly parses in under 4 seconds on a 16-core workstation.

These numbers are real, but conditional. The 30x figure is for the largest projects. The benchmarks don't disclose hardware specs or methodology for mid-sized projects in the 1,000 to 5,000 model range. If you're running 200 models, your parse time was already fine.

The Rust rewrite kills the GIL bottleneck, meaning all parsing and compilation happen locally without needing cloud compute to go fast. That's a genuine win. The v2 parser also enforces strict syntax: undefined macros and missing variables now fail at parse time instead of silently passing through to compile. This will break things. That's the point.

dbt Core stays Apache 2.0. The Fusion runtime that was previously proprietary is now open source. This is, on paper, the opposite of the license-restriction pattern everyone fears. Credit where it's due: they didn't have to do that.

But here's the part that matters for your wallet.

The 30% Cost Reduction Claim

The "30%+ infrastructure cost reduction" you keep seeing in headlines refers to dbt State, a caching layer that skips unchanged models. It's a separate, metered service. The Rust engine makes your laptop faster; dbt State cuts your warehouse bill. Different products, different problems.

dbt State works by caching SQL query hashes and warehouse timestamps, then only building models where upstream data or code actually changed. Obie Insurance reported 30% compute savings. EQT hit 50% cost reduction and 60% faster runtimes. dbt Labs internally claims 64% compute savings, roughly $400,000 annually.

The catch: dbt State bills at $0.094 per Daily Active Target Table. A DATT is any model, test, or seed that was skipped, cloned, or reused on a given day. You need to model the cost at your project's size today, then at 3 years out, and decide whether the warehouse savings still clear the bill. dbt's own documentation warns about exactly this.

Also: Python models always rebuild. dbt State cannot reuse them. If your team leans on Python for ML feature engineering, that layer gets zero benefit from the caching story.

The tools change every 18 months. The problems don't. Schema drift, late-arriving data, upstream teams breaking contracts without telling you. Those are eternal. A merger doesn't change that calculus.

The Open Source Question

I've watched this play out before. HashiCorp moved Terraform from MPL 2.0 to BSL 1.1 in August 2023. Redis abandoned BSD for SSPL in March 2024. Both cited cloud providers repackaging their open code. Both communities saw the pattern: open source commitments made during fundraising yield to commercial pressure once the cap table needs returns.

dbt Labs says they're going in the opposite direction. They open-sourced the Fusion engine and publicly stated that "we have wanted to ship more code in the open, not less." I believe that's genuine today.

The risk isn't license restriction. The risk is feature parity.

dbt Wizard, the AI-assisted authoring agent, launched in public beta on June 1. It requires a Starter, Enterprise, or Enterprise+ account. It's billed per token starting September 1, 2026. dbt Mesh, dbt Copilot, and dbt Canvas are all Enterprise-tier exclusives at $200 to $400 per developer seat per month.

Brooklyn Data Co. put it plainly: "The tool you're told to reach for is no longer the fully-open one." When dbt Labs' own recommended path includes closed-source components, the open source label on Core starts carrying less practical weight.

The Hacker News crowd summed up the fear: "Core is gonna stay unchanged while Cloud keeps gaining new features. Eventually, it will be end-of-life." I wouldn't make that prediction; Databricks continues investing in open-source Spark and Delta Lake while competing commercially. But Nexla's analysis correctly notes that "Fivetran is a company with zero history in open source and every incentive to drive users toward their paid products."

The merger didn't kill open source dbt. But it placed every high-visibility AI feature behind consumption pricing. The letter of the promise is intact. The spirit is evolving.

What Data Engineers Should Do Before Touching v2

The release candidate shipped September 2. No GA date announced. dbt Labs' roadmap document explicitly asks for community testing "against ever-bigger DAGs, custom macro implementations, and varied system configurations." Translation: they expect edge cases to surface.

Here's your checklist.

Test the v2 parser on v1. dbt Core v1.12 includes an opt-in , use-v2-parser flag. Run dbt parse , use-v2-parser against your project. If it passes, you're probably fine. If it throws on undefined macros or missing variables, those are real problems the v1 parser was silently ignoring.

Audit your CLI scripts. , models becomes , select. , partial-parse is gone entirely. Every CI/CD pipeline, Makefile, and wrapper script that invokes dbt needs a pass.

Check your artifact consumers. v2 produces Parquet metadata artifacts instead of JSON. If you have tooling that parses manifest.json for lineage, docs, or metadata pipelines, it will break. This is the migration risk most teams discover weeks after deployment.

Verify your adapter. Adapters for BigQuery, Databricks, Redshift, Snowflake, Spark, and DuckDB are in preview or beta. If you're on something else, check before you upgrade.

Don't confuse RC with GA. A release candidate is pre-production. Run it in a dev environment, compare outputs against v1, and wait for the stable release before migrating production DAGs.

Meanwhile, the Agents Schema initiative (a SQL-native standard for surfacing dbt lineage, metrics, and documentation as plain warehouse tables) is worth tracking. The idea is sound: give every tool that already queries your warehouse access to your metadata without new infrastructure. Atlan's research shows AI agents grounded in governance metadata score 38% higher on SQL accuracy than agents working from schema alone. Whether this standard survives contact with competing vendors is a different question entirely.

None of this changes the fundamentals of what makes a good data engineering career. Concepts transfer; tools don't. Data modeling, query optimization, understanding why things break. That's the study plan regardless of who owns your transformation layer. If you want to sharpen that foundation, we built snowflake schema practice on datadriven.io specifically because those concepts outlast whatever tool is hot this quarter.

The merger is done. dbt Core is still open source. The Rust engine is fast. The cost savings are real but metered. The AI features are paywalled. The question that actually matters: 12 months from now, will the feature gap between dbt Core and dbt Cloud be wider or narrower than it is today?

What's your bet?