I've watched 3 vendor mergers from inside a data team. Every press release said nothing would change for customers. Pricing changed within 18 months each time, and so did the roadmap.

So when Fivetran and dbt Labs closed their all-stock merger on June 1, 2026, I didn't care much about the announcement wording. I wanted to know what was in the license text, which features need a login, and what it means for the next person walking into a Data Engineering interview with "dbt" on their resume.

My position: dbt is still worth knowing, and the merger doesn't change that. What it changes is how much of your career you should tie to one vendor's ingestion and transformation layer. That number should be lower than it was last year. The skills that hold their value are the ones that work with any tool: modeling, debugging, and knowing when a vendor's number doesn't add up.

The June 1 releases from Fivetran and dbt

The facts first. Fivetran's completion release names George Fraser as CEO and Tristan Handy as President, and says the combined company serves "more than 100,000 data teams." The release title is about "Trusted AI Agents," because of course it is. Every 2026 press release legally has to mention agents.

That 100,000 figure needs one caveat. Fivetran describes it as a community "across analytics, data engineering, and AI initiatives," while dbt's boilerplate says 100,000 teams "use dbt." Those cover different things, and I couldn't find an independent count. Treat it as marketing.

The more interesting part is dbt Core v2.0. It shipped as an alpha on launch day and is built on the open-sourced Fusion runtime. Read the details, though, because the "dbt Core v2 is here" post describes 2 separate distributions:

  • A default binary that dbt describes as "containing some proprietary code"
  • A build "made up entirely of the Apache 2 open source code in the dbt-core repo"

dbt's own recommendation is "Almost certainly Fusion," which means the binary with proprietary code. The same post says "some features will only work if you've authenticated, either with a free login or a paid dbt platform account." It doesn't list which ones.

The install docs fill in part of the gap. The Apache-only build leaves out SQL comprehension, full LSP, dbt lint, and VS Code integration. dbt says that build is "for organizations that require the Apache 2.0 codebase specifically," so the open version exists, but dbt doesn't expect most people to run it.

To be fair to dbt Labs, the license has moved in the open direction. Fusion launched under Elastic License 2.0 in 2025, and the licensing FAQ's change log shows code "relicensed from ELv2 to Apache 2.0" on June 1, 2026. Handy's merger-day post says "Our commitment to open source isn't changing." I believe him about the license. The license isn't the part I'm worried about.

Apache 2.0 tells you who can read the code. The login gate decides who controls your workflow. Watch the gate.

The parse-speed claim is thinner still. The v2 post's only performance statement is "Significant parse time improvements, especially on the largest dbt projects." It gives no numbers, benchmarks, or test setup. It might well be faster; Rust parsers usually are. But "significant" with no number attached is a vibe, and I can't put a vibe in a capacity plan.

dbt State and the 30% number

The merger release also introduced dbt State, described as "a caching layer for data pipelines" that helps companies "reduce underlying infrastructure costs by 30% or more."

dbt's own product page for dbt State says something different: "Reduce warehouse compute by 15-30% on average." So the product page puts 30% at the top of the range, and the press release treats it as the minimum. Both come from the same company, and they don't agree.

I went looking for an independent benchmark and didn't find one. Every 30% figure I could trace leads back to dbt or one of its customers. The headline case study is Obie Insurance, where a senior data engineer said they were "saving at least 30% on compute costs." During the same period, that team was more than 90% through a Data Vault 2.0 migration and had moved to the Fusion engine. When you change your data architecture, your engine, and your caching layer at the same time, you can't say which one saved the money. Any DE who has done a migration knows that.

Other things to know before you put 30% in a budget deck:

  • Python models always rebuild, and so do custom materializations. If your project leans heavily on Python, the cache helps you less.
  • The quoted savings are gross. Pricing is per "daily active target table," and I found no published figure that subtracts that fee from the savings.
  • Change metadata (timestamps and SQL hashes) goes to a single US multi-tenant instance, which your compliance team will want to know about.
  • The status keeps changing. The release called it a preview, a September 2026 post declared it GA, and the docs still mark the state:* selectors as Beta.

I'm not saying it doesn't work. Skipping unchanged models is a good idea; most of us have hand-built a worse version of it with a last_modified check and some prayer. My point is economic. Engineer time costs more than compute, so before you spend a quarter adopting a caching layer, measure your own warehouse bill before and after on a project that isn't also being migrated. That measurement is the only one I'd trust.

Lock-in is the part that matters for your career

Before the merger, a typical modern stack had ingestion from one vendor and transformation from another. If Fivetran raised prices, you could move ingestion and leave your dbt models alone. If something went wrong with dbt, your connectors kept running. Each vendor knew you could swap it out without touching the other.

Now one company owns both layers. That isn't automatically bad. Integrated tools are often nicer to use, and I've spent enough nights gluing 2 vendors together through a webhook to see why people want it. But the merger-day posts don't say anything about pricing for existing customers, contracts, or connector changes. You'll see plenty of loud anecdotes online about Fivetran price increases; I couldn't verify any of them against a primary source, so I won't repeat the numbers. You don't need them anyway, because the missing pricing statement tells you enough.

Fivetran bought Tobiko Data, the company behind SQLMesh, in 2025, then donated SQLMesh to the Linux Foundation in March 2026. So the most obvious alternative transformation framework is now under neutral governance, and the company that owns dbt paid for it. Before the acquisition, Tobiko's founders argued that analytics engineers need an open standard "so their careers don't depend on one company." That was a competitor's opinion when they wrote it. Now it's partly the acquirer's donation strategy. Funny industry.

As a working DE, I'd start by finding your exit cost. The license won't trap you; your Jinja will. Count your macros. Count the models that use dbt-specific behavior you couldn't easily rewrite in plain SQL. That number is your real switching cost, and most teams have never measured it.

Keep ingestion and transformation separable on paper, even if both come from the same vendor. Land raw data in tables you own, with schemas you've documented. If you ever have to replace one layer, you want to replace one layer, not both.

Expect the upgrade itself to be strict. The v1.x support windows are already pushing teams to upgrade. dbt's upgrade guide says "All deprecation warnings must be resolved before upgrading," and the recommended path is v1.12 first. In v2, , models and -m now error, misspelled configs and unknown YAML keys error, and nonexistent macros fail at parse. Your project probably has a few of those. Every project I've inherited did. According to dbt's versions page, v1.11 leaves critical support on December 18, 2026, which is about 5 weeks away.

Then check your adapter. The documented v2 adapters are BigQuery, Databricks, Redshift, and Snowflake, with ClickHouse in private beta and Spark and DuckDB as CLI-only. Postgres, Trino, and Athena were described as "likely" before GA back in May 2025 and still aren't on the supported list. If you run on Postgres, v2 isn't ready for you yet.

The v2 post also says: "You don't have to move to v2.x today, tomorrow, or ever." That's true for now. Then Handy writes "we will simply have one engine: dbt." My guess, and it's only a guess, is that the Apache-only build ends up as a side option over time. Plan as if the free tier will lag behind.

What changes in the data engineering interview loop

On the hiring side, the evidence is thinner than people want. I looked for a primary dataset showing which dbt skills interviewers test and couldn't find one. What exists is prep-site content and vendor surveys, and dbt Labs ran its own State of Analytics Engineering survey, which now belongs to the merged company. So everything below is my opinion, based on running loops and sitting through a lot of them.

"I know dbt" was never the signal on any panel I've been on. Nobody cared whether you could write {{ ref() }}; you can learn that in an afternoon. We cared about whether you could explain why the model was incremental, what happens when data arrives 3 days late, and how you'd find out a test was passing while the numbers were wrong. Those questions were the same in the Informatica days, the stored procedure days, and the Airflow-plus-SQL-files days.

Expect questions about consolidation, because interviewers like to ask about whatever's in the news. If a team has just been through a 6-figure Fivetran renewal, someone on the panel will ask how you'd evaluate building your own ingestion versus buying it. Have an answer based on cost: engineer hours, connector maintenance, schema drift handling, and what happens when the vendor raises prices. "We used Fivetran because it was there" is a weak answer, and you should have a better one ready.

The strictness of v2 also gives you interview material. If you've done the 1.x to v2 upgrade, you have a real story about deprecated flags, configs that failed silently, and broken macros that suddenly showed up. That's a debugging story, and debugging is most of the job. Tell it in the STAR format and it'll beat any answer about features.

Testing is underrated, and you can use that. dbt's own survey found 72% of respondents prioritize AI-assisted coding, but only 24% prioritize AI-assisted pipeline management, the testing and observability side. The sample is 363 people and the survey is run by the vendor, so don't overread it. But it matches what I see: everyone wants to write code faster, and fewer people want to prove the code is correct. The candidate who can explain how they caught a pipeline silently dropping rows stands out from the 10 others who list "dbt tests" as a bullet point.

Indeed found 45% of data and analytics postings mention AI terms as of December 2025. That's a keyword count of posting text, and Indeed's own numbers say it's still a minority, so don't let it pull your prep away from the basics. Job postings change their vocabulary faster than interviewers change their questions. Your loop will still test SQL, modeling, and pipeline architecture.

If I were prepping now, I'd learn dimensional and wide-table modeling until I could argue for either one based on cost. I'd practice designing incremental loads with late-arriving data, and explaining a pipeline from source to dashboard on a whiteboard, including where it fails. For the architecture part, pipeline design practice is what DataDriven is good for; we wrote our problems to sit as close as we could get to the questions panels actually ask, without the vendor trivia.

If you only know dbt, learn the SQL dbt generates. If you only know Fivetran, build one ingestion job by hand with retries, schema changes, and alerting. You'll understand what you're paying for, and you'll have something to say when the interviewer asks what happens if the vendor goes away.

The tools have changed owners, but the work hasn't: schema drift, late data, and upstream teams breaking contracts without telling you.

So, for those of you running dbt in production: are you upgrading to v2 this quarter, staying on 1.x as long as the support windows allow, or quietly testing SQLMesh in a branch nobody knows about?