On October 13, 2025 Fivetran and dbt Labs announced a merger agreement. On June 1, 2026 it closed. The combined company is led by Fivetran's George Fraser as CEO and dbt Labs' Tristan Handy as President, and it positions itself as end-to-end data movement, transformation, and activation: Fivetran for loading, dbt (and SQLMesh, from the 2025 Tobiko Data acquisition) for transformation, and Census (acquired May 2025) for pushing data back out.
Clients have been asking us the same dozen questions since the announcement, so here they are in one place, with the practical answer for a team that runs Fivetran today. Product details will keep changing; where something is uncertain, we say so.
Does anything break on day one?
No. Your Fivetran connections keep syncing. Your dbt project keeps building. Nothing about the merger changes how either product works today, and both products continue as they were. Treat this as a roadmap event, not an operational one.
Does dbt Core stay open source?
Yes. dbt Core remains open source under the Apache 2.0 license. Your models, macros, and packages are yours and run anywhere dbt runs. If your risk register had "vendor pulls the open-source rug" on it, the commitment so far is the opposite; keep watching the release cadence rather than the press releases.
I run dbt Core on a cron. Do I need to move anything?
Not today. But the merger makes one change in emphasis worth acting on: transformations should run when the sync completes, not on a clock. Fivetran Transformations can trigger a dbt job on sync completion, which removes the classic failure of models building against a half-loaded source at 02:00 because the sync ran long. If you stay on your own scheduler, wire source freshness checks so that a late sync fails the run loudly instead of producing quietly wrong numbers.
Fivetran Transformations vs. dbt Cloud jobs: which one?
Both run dbt. The differences that matter:
| Fivetran Transformations | dbt Cloud | |
|---|---|---|
| Trigger | On Fivetran sync completion, or schedule | Schedule, API, CI, or orchestrator |
| Project source | Quickstart packages or your Git repo | Your Git repo |
| Development | Your local environment | Cloud IDE, Studio, CLI |
| CI / Slim CI | Bring your own (GitHub Actions etc.) | Built in |
| Multi-source DAGs | Per-connection triggers | Any dependency graph |
| Best for | Fivetran-centric stacks, fast start | Existing dbt practice, complex orchestration |
Our rule of thumb: if most of your sources arrive through Fivetran and you do not yet have a dbt practice, start with Fivetran Transformations and Quickstart models, then move to your own repository as the project grows. If you already have dbt Cloud with CI and environments set up, keep it and use Fivetran's completion trigger as the entry point. Expect the two to converge; the point of the merger is that you should not have to choose.
What are Quickstart data models?
Pre-built dbt packages, maintained by Fivetran, that turn the raw schema of a specific connector (Salesforce, HubSpot, NetSuite, Google Ads, and many more) into cleaned staging tables and a few standard marts. They run as Fivetran Transformations without you managing a project. They are a good first transformation layer and a poor last one: as soon as you need company-specific logic, bring your own project and use the packages as dependencies.
We have a pile of scheduled SQL in the warehouse. What now?
This is the common case and the merger is a good excuse to fix it. The migration we run:
- Inventory every scheduled query, view chain, and stored procedure. Record who consumes the output.
- Classify each into staging (one-to-one with a source table), intermediate, or mart.
- Port to dbt models with the legacy output kept running in parallel.
- Prove parity with a test that compares row counts and key aggregates between the old and new outputs for a few cycles.
- Switch consumers and turn off the old jobs.
A simple parity test, as a dbt singular test:
-- tests/parity_orders_daily.sql
with new as (
select order_date, count(*) as n, sum(total_cents) as total
from {{ ref('fct_orders_daily') }} group by 1
),
old as (
select order_date, count(*) as n, sum(total_cents) as total
from legacy.orders_daily group by 1
)
select coalesce(new.order_date, old.order_date) as order_date
from new full outer join old using (order_date)
where new.n is distinct from old.n
or new.total is distinct from old.total
The test passes when it returns zero rows.
Should we look at SQLMesh instead of dbt?
Possibly. SQLMesh's virtual environments, column-level lineage, and cheaper incremental backfills solve real problems for large projects, and it can run existing dbt projects. For a new team with a modest project, dbt's ecosystem and hiring pool still win. For a team fighting slow CI on a thousand-model project, a SQLMesh evaluation is worth a week. Both are now first-party to the same vendor, so this is a technical decision rather than a procurement one.
What about Census and activation?
Reverse ETL is now part of the platform: modeled data in the warehouse can be synced back to CRM, marketing, and ad tools without a third vendor. If you have a clean customer model, this is the fastest way to turn the merger into something your sales team notices. See our data activation service.
How do we prepare a combined account?
Things to do now, regardless of how packaging evolves:
- Put every transformation in version control. Anything still living only in a warehouse scheduler will be the hardest thing to move.
- Wire transformations to sync completion. Even on your own scheduler, add source freshness gates.
- Name owners. Every connection and every mart should have a person. Consolidated billing and consolidated admin make orphaned objects more visible, not less.
- Review MAR alongside transformation compute. With both on one bill, the cheapest fix for a slow model is sometimes deselecting a column upstream. See our MAR pricing tutorial.
- Watch the docs, not the headlines. Feature changes land in fivetran.com/docs and docs.getdbt.com before they are announced anywhere else.
Timeline, for the record
- May 1, 2025: Fivetran acquires Census (reverse ETL).
- September 2025: Fivetran acquires Tobiko Data (SQLMesh).
- October 13, 2025: Fivetran and dbt Labs announce a merger agreement.
- June 1, 2026: merger completes.
If you want help deciding where your transformation layer should live, our Fivetran + dbt transformations consulting starts with a written assessment.