After the Fivetran-dbt Labs Merger, Should You Stay on dbt Core, Move to Fusion, or Switch to SQLMesh?

For most teams the answer is to stay on dbt Core today, test Fusion on a copy of your project, and keep your models portable rather than switch tools in a panic. The dbt docs still describe the open-source runtime as Apache 2.0, and the merger changes who owns dbt Labs, not the license on code you already run. Nothing published so far forces a migration. What the merger changes is your negotiating position and your risk surface, and those are worth planning for before a renewal forces the decision.

Key Takeaways

• •dbt Core remains Apache 2.0 open source, and the companies have publicly committed to maintaining it, according to Peliqan's merger explainer.
• •The real risk to Core is not a license change but investment drift: community concern is that engineering effort shifts to Fusion and the paid dbt platform, leaving Core with bug and security fixes.
• •Fusion is the Rust-based engine; per the dbt docs it is free to use, with some advanced capabilities unlocked by signing in to a dbt platform account.
• •SQLMesh was donated by Fivetran to the Linux Foundation, per Fivetran's press release, which makes it a credible vendor-neutral hedge.
• •The lowest-regret move for most teams is to stay on Core, trial Fusion on a branch, and avoid macros and packages that lock you to one engine.

What actually changed with the merger

Fivetran and dbt Labs agreed to an all-stock merger, first announced in October 2025. Peliqan's explainer says the combined company serves more than 100,000 data teams, names George Fraser as CEO and Tristan Handy as President, and describes a single path from raw data to what the companies call AI-ready data. A caveat on that source: Peliqan is a competing vendor, and its article gives a completion date of June 1, 2026 while its own FAQ says the deal is still subject to closing conditions. Check the companies' own announcements for the current status before you cite it internally.

Two things did not change. The Apache 2.0 license on the open-source dbt runtime is the same, so the code you run today cannot be relicensed out from under you. And your project files, including SQL models, YAML and tests, are still plain text in your own repository. What did change is the incentive structure. dbt used to be a neutral layer that sat between any ingestion tool and any warehouse. As a Fivetran-owned product, the open question is whether the roadmap and pricing will favor teams that use both.

That distinction matters for how you respond. A license change would be an emergency. A roadmap tilt is a slow-moving risk that you manage with portability, testing and calendar discipline. Treating the second like the first leads teams to rushed migrations that cost more than any plausible price increase.

The three risks practitioners are worried about

The first is Core going into maintenance mode. Peliqan's FAQ flags the concern that engineering investment shifts toward the dbt platform and Fusion, leaving Core with mainly bug fixes and security patches. That is a community worry, not an announced plan, and the companies have said they will maintain Core. Watch the release cadence and the open issues on the repository rather than the press releases. A quiet changelog for two or three quarters is a better signal than any blog post.

The second is feature gating. The dbt docs say that with Fusion, some capabilities unlock with a free sign-in to any dbt platform account, and the docs point to a separate feature availability page for the breakdown. Read that page against your own project, line by line, because the answer depends on which features you use. If your workflow depends on editor-level SQL comprehension, you may care about a gated feature. If you run dbt build in CI, you may not.

The third is pricing. Combined pricing has not been published, and Peliqan's FAQ cites Fivetran's 2025 price increases of 4 to 8 times for some customers as the reason the community expects bundled offers and upward pressure, especially for teams renewing after close without a tested alternative. We would treat that as a prompt to build the alternative before the renewal conversation, not as a prediction.

Where Fusion fits

The dbt docs describe the Rust-based engine as the current generation, v2, and the Python-based version as v1, still maintained. They say v2 builds on the Apache 2.0 open-source runtime, and that a free, fully open-source OSS distribution exists for organizations that must use the OSS runtime. The docs also list SQL comprehension across multiple dialects, which can catch errors before they reach your warehouse. Those are real benefits for teams with large projects and slow feedback loops.

Our read is that Fusion is worth a trial, not a rushed cutover. Create a branch, install the new engine, run your full build against a development schema, and diff the outputs against your current production run. Note which packages and custom macros fail to parse, because that list is your portability debt. The docs page we read did not publish speed numbers, so measure your own project instead of trusting a headline multiplier.

Also read the v2 license agreement the docs link to. It is separate from the Apache 2.0 runtime terms, and the docs page does not summarize it. Have whoever owns vendor review in your company read it, because the answer to can we run this in production without a paid account depends on the exact wording, not on our summary.

Where SQLMesh fits

SQLMesh came to Fivetran through its September 2025 acquisition of Tobiko Data. According to Fivetran's press release, the company then contributed it to the Linux Foundation to be governed through an open community model, with the code and documentation staying public on GitHub. That gives you a transformation framework with neutral governance, which is the property many teams now want most.

The tradeoff is switching cost. SQLMesh has its own project structure, its own model definition syntax and its own planning workflow. It can read dbt projects, so you can trial it without rewriting everything, but a full move means re-validating every model, test and deployment path. For a small project that is a few weeks. For a project with hundreds of models, packages and downstream dashboards, it is a funded migration with a rollback plan.

We would not switch to SQLMesh purely because of the merger. We would switch if you have a concrete need it serves better, such as its approach to environments and change planning, or if your procurement team requires a vendor-neutral foundation home for core tooling. Without one of those, a trial plus portable models gives you most of the insurance at a fraction of the cost.

Decision table: stay, move, or switch

A five-step plan that keeps every option open

• •Inventory: list every package, macro and custom materialization, and mark the ones that only work on one engine.
• •Pin and snapshot: pin your dbt version, tag the repository, and save a production run's row counts as a baseline.
• •Trial Fusion: run the full build on a branch and diff results against the baseline.
• •Trial SQLMesh: point it at a copy of the project and record what it can and cannot read.
• •Decide at the next renewal date, not today, with measured effort and risk for each path.

The point of the plan is that you walk into the renewal with numbers. If both trials pass, you have use and a real choice. If one fails, you know what to fix while you still have time, and no one has to defend a migration they started in a hurry.

Migration is the part teams underestimate, because the SQL is rarely the hard part. The hard part is the lineage, tests and downstream consumers that depend on the models. Agents can take on the mechanical work here: our Migration Agent analyzes legacy SQL and emits dbt or SQLMesh targets, and the Pipeline Agent can rerun builds and compare outputs. A person still signs off on parity, because that is a judgment about your business, not a diff.

Frequently Asked Questions

Is dbt Core still open source after the merger?

Yes. Per Peliqan's explainer and the dbt docs, the open-source runtime remains under Apache 2.0, and the companies have publicly committed to maintaining Core. The open question is how much engineering investment it receives over time, which you can track through releases and issues.

Is Fusion free to use?

The dbt docs say dbt is free to use, with some capabilities unlocked when you sign in with any dbt platform account. A separate v2 license agreement applies, so read it, and check the feature availability page against the features you rely on.

Is SQLMesh a safe alternative?

It is a credible one. Fivetran contributed it to the Linux Foundation, and the code stays public on GitHub. Safety here is mostly about migration effort, so trial it on a copy of your project and measure parity before committing.

Should I migrate now?

Not unless you have a concrete need. Stay on Core, trial both alternatives, keep your models portable, and decide at your next renewal with data in hand.