dbt Core v2.0 Goes Apache 2.0: What Data Engineers Should Know

I've had the license on a tool I ran in production change under me more than once. Every time, the headline said "open" and the details lived on a page nobody on my team read until legal sent an email asking what exactly we'd deployed.

On June 1, 2026, Fivetran and dbt Labs closed their merger and announced that the Fusion engine runtime is now dbt Core v2.0, licensed under Apache 2.0. dbt's own licensing docs describe dbt v2 as proprietary. Both statements are accurate. They describe different artifacts, and if you build on dbt or interview for roles that use it, you need to know which is which.

My take: the open source runtime is real, and it's good news. The binary most people install is a separate thing with separate terms. None of it changes what you should study, because the concepts underneath dbt outlived every vendor that has owned the tooling around them.

What Fivetran and dbt Labs announced at close

The joint merger announcement confirms an all-stock deal, first announced October 13, 2025. George Fraser stays CEO and Tristan Handy becomes President. No valuation, price, or exchange ratio was disclosed. Back in October 2025 the companies said the combined business would be "approaching $600M" in ARR. The closing release doesn't repeat that number.

Then there's the "100,000 data teams" figure. In October 2025, Fivetran's release said "more than 80,000 data teams use dbt." In June 2026 the body of the release says the combined company supports "more than 100,000 data teams," and the boilerplate at the bottom says more than 100,000 teams use dbt. One of those is a combined count and the other is dbt-only, and the release never defines "data team" or says whether overlapping customers were deduplicated. Treat it as the company's own count. It doesn't tell you anything independent about adoption.

The product list at close:

• dbt Core v2.0 (alpha): "the open sourcing of the dbt Fusion engine runtime," under Apache 2.0
• dbt State (preview): a caching layer, with a claimed infrastructure cost cut of "30% or more"
• dbt Wizard (beta): no license stated
• Agents Schema: called "an open source standard for agentic context," with no status given in the release

There's also a subplot that gets less attention. In September 2025 Fivetran bought Tobiko Data, the company behind SQLMesh and SQLGlot, which is the main open source competitor to dbt. In March 2026 Fivetran donated SQLMesh to the Linux Foundation, which says the project "will remain vendor neutral." So the company that now owns dbt bought the biggest open alternative and then gave it to a foundation. The public record doesn't say why. If you're betting on SQLMesh as a hedge, wait until the governance details and roadmap are published.

Devin Pratt, an IDC analyst, told TechTarget that "the real test is keeping the DBT open-source community's trust through the transition." That's his opinion, and I agree with it. Trust gets built in license files and changelogs, and press releases don't count.

Apache 2.0 vs. the licensing docs: which dbt you're running

The dbt Core v2 launch post by Joel Labes and Grace Goheen says the shared runtime code, which dbt "previously committed to releasing publicly under the ELv2 license is now under the Apache 2.0 license as dbt Core." The dbt-core repo README backs that up: main contains the Apache 2.0 source of v2.0. The old dbt-fusion repo is archived. That part is clean, and it's a real improvement.

The same post also says the Fusion binary "contains some proprietary code," that dbt has "relicensed the Fusion binary to be more permissive than ELv2," and that some premium features need a free login or a paid dbt platform account.

Now the dbt licensing docs, last updated September 16, 2026: "dbt v2 is proprietary to dbt Labs, made available under the dbt Product Licensing Agreement." The Apache 2.0 distribution is called dbt OSS. dbt v1 remains fully Apache 2.0.

So in practice there are 2 distributions:

• dbt OSS (dbt-oss package): the Apache 2.0 runtime. You can read, fork and ship it.
• dbt (the recommended dbt package): bundles proprietary code under the Product Licensing Agreement, which bars reverse engineering or deriving source code. Local production use is free without an account. Some features sit behind a login.

The naming makes this harder to follow. Across dbt's own pages, the same lineage of software has been called Fusion, dbt Core v2, dbt v2, dbt OSS, and plain dbt. The licensing FAQ changelog shows the June 1 update "Removed ELv2 references," and a September 15 entry renamed "dbt Fusion engine" to "dbt" and "dbt Core v2" to "dbt OSS." The press release uses one vocabulary and the docs use another.

The license has moved before. In May 2025, when Fusion launched under ELv2, dbt Labs wrote, "The license for dbt Core is not changing." That was true when they wrote it. A year later the runtime moved to Apache 2.0 and the full binary became proprietary under a separate agreement. Usage rights got broader and the remaining closed code stayed closed. Licenses on the same product can change in both directions within 12 months.

"Fusion is Apache 2.0" is wrong. "The dbt v2 runtime is Apache 2.0 as dbt OSS, and the full binary is proprietary" is correct. Say the second one in your interview.

Status is the other moving target. At the merger, v2 was labeled alpha. By the September 16 dbt Summit, dbt Labs called v2 and dbt State "Now GA". dbt's upgrade docs, updated October 8, still show alpha, beta, and preview labels at the adapter level and don't give a GA date. So "GA" may depend on which warehouse you run. Check your adapter before you plan a migration around it.

This week, open your project's requirements file or lockfile and find out which package name is in it. Then find out who on your team approved it. In my experience the answer is usually "whoever set up the repo 2 years ago," and you have about the same odds of that being documented as of a 1,500-line stored proc having accurate comments.

The 30% savings claim and Agents Schema

The dbt State savings figure has been worded 3 different ways in 3 months:

• June 1 press release: "reduce underlying infrastructure costs by 30% or more"
• Fivetran's June blog: "more than 30% on average across production runs" of dbt-generated compute
• September dbt Summit post: "an average 15-30%+ reduction in warehouse compute"

"Infrastructure costs" and "dbt-generated compute" measure different things. None of these sources publishes a sample, a baseline, or a methodology. The customer numbers that do appear vary widely: CarGurus reported a 9% compute reduction in dbt's own State post, Virgin Media O2 reported 25%, and RxBenefits reported 59%. Each of those is a single company's self-reported result.

My read is that caching state and skipping models whose inputs haven't changed is good engineering, and I've been writing hand-rolled versions of it since before dbt existed. Whether you save 9% or 59% depends on how much of your DAG was rebuilding unchanged data every night. If your whole project is incremental models with tight predicates, the savings are small. If someone scheduled a full refresh of 400 models every hour because "it was easier," you'll save a lot, and you also have a bigger problem.

Engineer time costs more than warehouse compute. A 30% cut on a small Snowflake bill won't pay for a migration that takes 2 engineers a quarter. Measure your own baseline before you trust anyone's average, including mine.

Agents Schema is the AI part of the announcement. The idea is a single AGENTS schema in your warehouse holding tables like AGENTS.DBT_MODEL and AGENTS.LOOKML_VIEW, so any agent that can run SQL can read your semantic context. The GitHub repo is MIT licensed with "Copyright (c) 2026 Fivetran Inc." while sitting under the dbt-labs org. When I looked it had 145 commits, but nobody had cut a release tag or published a spec, a versioning policy or a governance body. The managed product built on it, Fivetran Context Layer, is in preview and limited to Snowflake, BigQuery, or Databricks in North America.

Fivetran's own Context Layer docs say, "We recommend using Agent Context MCP because it can be more accurate and token-efficient than Agents Schema." So the open standard ships alongside a recommendation to use the proprietary service. An open table layout is useful, but whether you can move your context elsewhere depends on whatever engine fills those tables. Ask about that before you believe "without lock-in."

The v2 question in your next data engineer interview

I've sat on enough hiring panels to know how this will go. Someone will ask, "We're on dbt. Would you upgrade to v2?" Most candidates will either recite the press release or panic. Both of those lose.

A stronger answer starts by naming the artifact: spec, runtime, binary or hosted platform. Each one has different terms, and that one sentence shows you understand vendor risk better than most of the people interviewing you. Then separate the vendor's claims from your measurements: "The vendor says 15 to 30%. I'd run it against our own baseline on a staging environment for 2 weeks before committing."

After that, talk about exit cost. Your SQL is fairly portable, since SQLGlot is MIT licensed and handles dialect translation. Your tests, lineage, state and deployment workflow are harder to move, so that's where the lock-in is. Finally, bring it back to the model. If your grain is right and your models are idempotent, the transformation tool is replaceable. If they aren't, no license will help you.

That last point is the one I keep repeating. The topics that come up in nearly every DE interview loop are DAG dependencies, incremental logic, dialect differences across warehouses, and "what happens if this job runs twice?" Those are concepts, and every one of them applies to dbt v1, dbt v2, SQLMesh, Dataform, or a cron job someone wrote in 2014.

I did around 20 loops in a single job search once. I was never asked about a license. I was asked about modeling all the time, and some of those times I gave answers I'd rather forget. So don't spend your prep weekend memorizing Fusion feature flags. Spend it on fact table grain, slowly changing dimensions, and explaining why a model is incremental. If you want practice on the part that survives every vendor reshuffle, data warehouse design is covered on datadriven.io. We built it for that kind of prep, and it's where we send people who ask what to study after the tool news cycle settles down.

For DEs already running dbt in production, the checklist is short:

• Find out which package you install, dbt-oss or dbt, and write it down.
• If you redistribute dbt to anyone (consultancies, platform teams, managed services), read the Product Licensing Agreement in full. Sections 3 and 4 govern redistribution.
• Treat the 30% number as a hypothesis to test.
• Treat Agents Schema as an experiment until it has a release tag and a governance doc.

I've been through enough of these big-announcement cycles to know the pattern. The press release comes out in June, the naming gets cleaned up in September, and in 2 years everyone's debugging the same late-arriving data and broken upstream contracts with a different binary. I've watched the tooling turn over about every 18 months while those problems stayed put.

Which dbt package is in your production requirements file right now, and did anyone check its license before it got there?