Fivetran dbt merger dbt core open source: what stays open, what changes, and what to do

dbt Core is published under the Apache 2.0 license in the dbt-core GitHub repository, and a corporate merger cannot retroactively revoke a license on code that has already been released: every version you can download today stays usable and forkable. What a merger can change is the roadmap, meaning where engineering effort goes. The practical question is not whether dbt Core disappears, but whether new capability lands in dbt Core or in the newer Fusion engine, which ships under a different license.

Key Takeaways

• •Released versions of dbt Core remain Apache 2.0, and anyone can fork them regardless of what Fivetran or dbt Labs does next.
• •The dbt Fusion engine lives in a separate repository, dbt-fusion, and is not licensed the same way as dbt Core. Read its LICENSE file before adopting it.
• •Fivetran also owns SQLMesh through its Tobiko Data acquisition, so one vendor now controls the two most prominent open-source SQL transformation frameworks.
• •The lowest-risk posture is to keep models in portable SQL, pin versions, and avoid vendor-specific features you cannot migrate away from.
• •Merger announcements are roadmap signals, not license events. Watch the repositories, not the press releases.

Fivetran dbt merger dbt core open source: what we know and what we do not

We should separate facts from speculation, because the topic attracts a lot of the latter. Fivetran and dbt Labs announced they would combine in October 2025, and our understanding is that the deal has since closed. Check the official announcements for the exact terms and dates, since we are not the authoritative source on deal details. Fivetran had earlier acquired Tobiko Data, the company behind SQLMesh.

What we can verify directly is the code. dbt Core's license is in the repository root. Fusion's license is in its own repository. Those two files, not any blog post (including this one), are what governs your rights. We recommend reading both before you make a platform decision, and re-reading them whenever you upgrade a major version.

What we cannot know is intent. Public statements from the companies about keeping dbt Core open are worth reading, but they are commitments about future behavior, not license terms. In our opinion, the sensible response is to plan for the case where dbt Core receives fewer new features than Fusion, and to decide in advance what that would mean for your team.

dbt Core vs Fusion vs SQLMesh: how the options compare

The table below summarizes the three transformation options most teams are weighing. It reflects our reading of each project as of this writing; confirm license and feature details against the linked repositories, because these change.

dbt Core wins on ecosystem. The package hub, community answers and the number of engineers who already know it are real advantages that no alternative matches today. SQLMesh wins on some technical design points, particularly around environments and state. Fusion is likely where the vendor's attention goes. None of these is wrong; they optimize for different risks.

What the merger changes for your team

For most teams the near-term change is zero: your dbt Core project still runs, your CI still passes, and your packages still resolve. The decisions that matter are medium-term, and they depend on how you use dbt today.

• •Teams on dbt Core with their own orchestration (Airflow, Dagster, Prefect): pin your version, track the repository, and test Fusion in a branch without committing to it.
• •Teams on dbt Cloud: pricing and packaging are the vendor's to set. Review your contract's renewal terms and ask what bundling with Fivetran would do to your invoice.
• •Teams already using Fivetran for ingestion: expect tighter integration between ingestion and transformation. That can be convenient, and it can also deepen lock-in. Decide which you value.
• •Teams with a mixed or multi-warehouse stack: portability matters most. Keep logic in standard SQL where possible.

A decision framework: stay, test Fusion, or move

We would not recommend an emergency migration. Nothing about the merger breaks a working project. We would recommend a deliberate, low-cost hedge in three steps.

• •Stay on dbt Core if your project is stable, your team is productive, and you do not need Fusion-only features. Pin versions and subscribe to release notes.
• •Test Fusion if parse and compile time hurt your workflow or you want its editor tooling. Run it against a copy of your project and record what breaks. Check the license against your legal requirements first.
• •Evaluate SQLMesh or another framework if vendor concentration worries you, or if virtual environments and built-in state would remove infrastructure you maintain today. Be honest that this one is a real migration, and note it is now under the same corporate umbrella.

If you want a neutral view of whether your current project is portable, the exercise is the same in every case: inventory the Jinja macros, packages and adapter-specific SQL you depend on. Those are what make migration expensive, not the model files themselves.

Where agents fit into a transformation migration

Migration cost is mostly mechanical work: translating macros, rewriting tests, mapping lineage and validating row-level parity. That is the kind of work AI coding agents handle well when they have context about your project. Our Migration Agent analyzes legacy SQL and ETL and emits dbt, SQLMesh or Iceberg targets, chaining with the Schema Agent to map blast radius before anything changes. It is MCP-native, so you can invoke it from Claude Code or Cursor, where your engineers already work.

The open-source edition is read-only by default, which suits a migration assessment: it can tell you what a move would touch without writing to your warehouse. In practice, the useful questions are the ones engineers already ask, such as "What's the blast radius if I drop this column?" or "Is the customer_id join safe after the migration?". Our Pipeline Agent covers the orchestration side across Airflow, Dagster, Prefect, dbt and Fivetran, so you are not locked to one transformation engine when you rewire pipelines.

We covered adjacent tooling choices in separate posts on our resources pages, including metadata catalog alternatives. The same principle applies: keep context in a layer you control, so changing a vendor does not mean rebuilding your institutional knowledge. Agents connect to tools through the Model Context Protocol, an open specification, which is what makes that portability possible.

Frequently Asked Questions

Will dbt Core stay open source after the Fivetran and dbt Labs merger? Released dbt Core versions are Apache 2.0 and will stay that way; a license on published code is not revoked by a merger. Future releases depend on the maintainers, so check the repository's LICENSE and release cadence rather than relying on announcements.

Is dbt Fusion open source? Fusion has its own repository and its own license terms, which differ from dbt Core's Apache 2.0. Read the LICENSE file in the dbt-fusion repository and have your legal team confirm it fits how you plan to use it, especially if you embed it in a commercial product.

Should we migrate from dbt Core to SQLMesh because of the merger? Not as a reaction to the merger alone. SQLMesh has real technical advantages, but Fivetran owns it too, so it does not remove vendor concentration. Migrate if its design solves a problem you have today.

What is the safest way to reduce lock-in? Keep models in portable SQL, minimize custom macros and adapter-specific functions, pin tool versions, and store lineage and documentation outside any single tool. A portable context layer matters more than which framework you pick.

Can an AI coding agent help with a dbt migration? Yes, for the mechanical parts: translating macros, generating tests and checking parity. A human should still review changes and approve writes to production. Tools like Claude Code can run these tasks against your repository when connected to MCP servers that expose your project context.