Fivetran vs Airbyte vs dbt: Choosing a Data Stack After the Merger
Fivetran and dbt Labs completed their merger on June 1, 2026, so two of the three are now one company. They were never competitors anyway: Fivetran and Airbyte move data, dbt transforms it. The real 2026 question is whether to buy movement and transformation from one vendor, from two, or from neither.
Almost every "Fivetran vs Airbyte vs dbt" comparison on the internet was built on a category error, and the merger has now made that error structural. If you are evaluating these tools, start by getting the shape of the market right, because the answer to "which one" depends entirely on realising you are not choosing one.
What changed on June 1, 2026?
The merger of Fivetran and dbt Labs, announced on October 13, 2025 as an all-stock transaction, formally completed. The combined company operates as Fivetran + dbt Labs, with George Fraser as chief executive and Tristan Handy as president; both carry the co-founder title. At announcement the companies said the combined business would approach $600 million in annual recurring revenue after close; at completion they put the combined community at more than 100,000 data teams.
Same day, dbt Labs published the first alpha of dbt Core v2.0, rebuilt on the Rust-based Fusion engine. That release carries a licensing change that matters more than the merger for some buyers, and it has moved quickly since: a first beta on August 10, a second on August 18, and release candidate 1 on September 2, 2026. It gets its own section below.
The merger headline also hides a pattern. This is the third transformation-or-activation asset Fivetran has taken on in a little over a year: it agreed to acquire Census, the reverse-ETL vendor, in May 2025 (now sold as Fivetran Activations), acquired Tobiko Data, the company behind SQLMesh, in September 2025, then contributed SQLMesh to the Linux Foundation in March 2026 before closing the dbt deal. One company now spans ingestion, transformation, and activation.
The strategic framing from the combined company is about being the data infrastructure layer for AI agents — governed, high-quality, semantically rich data for systems that act on it. Treat that as direction rather than delivered product, but it does tell you where the roadmap points.
These were never three competing products
The comparison people search for lumps together two different jobs. Getting this straight eliminates most of the confusion.
| Tool | Job | Competes with |
|---|---|---|
| Fivetran | Extract and load — move data from sources into the warehouse | Airbyte, cloud-native ingestion, hand-written extractors |
| Airbyte | Extract and load — same job, source-available core you can self-host | Fivetran |
| dbt | Transform — model data already in the warehouse, with tests and version control | SQL scripts, orchestration frameworks, SQLMesh (now a Linux Foundation project) |
So "Fivetran vs dbt" was always a bit like "trucks vs warehouses." You will likely end up with one of each. The genuine head-to-head is Fivetran against Airbyte, and the genuine question about dbt is whether you use the open-source distribution or pay for the commercial one.
ELT, and why the order matters. Extract and load first, transform afterwards inside the warehouse. Cheap cloud storage and elastic compute made it cheaper to land raw data and transform it in SQL than to transform in flight. That single architectural change is why an ingestion tool and a transformation tool are separate products rather than one ETL suite — and why the merged company is interesting rather than redundant.
Is dbt still open source?
Yes, and it got cleaner. This is the development most likely to affect a real procurement decision.
The Fusion engine originally shipped under the Elastic License v2, which is source-available but not on the Open Source Initiative's list of approved licences — a genuine blocker for organizations whose licence policy stops at Apache 2.0 and MIT. With dbt Core v2.0, the code that lived in the dbt-fusion repository under ELv2 was moved into the dbt-core repository under Apache 2.0. dbt Labs' own licensing FAQ, updated June 1, 2026, says nothing in dbt Core remains under ELv2, and the repository's licence file is Apache 2.0.
What stays proprietary is the Fusion distribution: a free-to-download binary built on that same engine that adds features such as advanced SQL comprehension, linting, and column-level lineage, some of them gated behind a dbt platform account. You do not need it to run dbt. You need it for those extras.
Here is how the licences actually line up today, because the Airbyte rows surprise people:
| Component | Licence | OSI-approved open source? |
|---|---|---|
| dbt Core v2.0 (and v1.x) | Apache 2.0 | Yes |
| dbt Fusion distribution | Proprietary (dbt Product Licensing Agreement); free to download | No |
| Airbyte platform | Elastic License v2 | No — source-available |
| Airbyte connectors | Airbyte-maintained strategic connectors ELv2 since 2023; community connectors mostly MIT | Mixed |
| SQLMesh | Apache 2.0, Linux Foundation governance since March 2026 | Yes |
So the licence conversation has flipped. For years the objection was that the fast dbt engine was source-available. Today the transformation layer is fully OSI open source, and it is the independent ingestion alternative, Airbyte, whose platform sits under ELv2 — the same licence dbt just left. ELv2 is permissive for internal use; its restrictions are on offering the software to others as a managed service and on tampering with licence keys, so self-hosting Airbyte for your own pipelines is fine in practice. But if your policy says "OSI-approved only", which is common in regulated industries and in anything you intend to ship to a client, Airbyte's platform now needs the legal review that dbt no longer does.
Note the maturity caveat: v2.0 is a release candidate as of early September 2026, not a general release. The stable line is v1.12, and dbt Labs' own migration advice is to move to v1.12 first and validate your project with the v2 parser before upgrading. For production work today, that argues for v1.12 while v2 finishes, not for skipping dbt.
How do the pricing models differ?
Compare models, not sticker prices, because the models behave very differently as you grow and because published prices change faster than any article can track.
| Option | Pricing model | Where it hurts |
|---|---|---|
| Fivetran | Consumption, priced per connection on monthly active rows (MAR) | Chatty sources and frequent syncs; cost tracks change volume, not value |
| Airbyte Cloud | Volume-based credits on the Standard tier (from $10 a month); capacity pricing in Data Workers on Pro and Enterprise | Forecasting; capacity tiers mean paying for headroom |
| Airbyte self-hosted | No licence fee — source-available under ELv2 | Infrastructure plus real engineering hours to run and upgrade it |
| dbt Core | Free, Apache 2.0 | You supply orchestration, CI, and scheduling |
Two Fivetran changes that took effect on January 1, 2026 are worth knowing if you priced it earlier. Deletes in the source now count as paid MAR, where before they were free, and every standard connection generating between one and a million MAR carries a $5 monthly minimum. Neither matters at scale. Both matter to a small company running twenty low-volume connectors, which is exactly the profile that used to make Fivetran nearly free.
The trap in the bottom half of that table is treating "free" as free. Self-hosting an ingestion platform means someone owns a Kubernetes deployment, connector upgrades, credential rotation, and the pager. For a team with a platform engineer, that is a reasonable trade. For a five-person company where the same person does data and everything else, a subscription is usually cheaper than the alternative — the alternative just charges in evenings instead of dollars.
Model your own volumes before comparing anything. A consumption model and a capacity model can differ by an order of magnitude in either direction depending on how much your source data actually changes, and vendor calculators are not neutral.
What should a small company actually do?
Start from the smallest thing that works and add tools when a specific pain appears, not in anticipation of it.
- A managed warehouse. Non-negotiable, and the one place to spend early. Everything else attaches to it.
- dbt Core, in version control, from day one. Transformation logic that is tested and reviewable pays off at almost any scale the moment more than one person relies on the numbers. This is the cheapest discipline in the stack and the one small teams skip most often.
- The cheapest ingestion that works. For a handful of sources with decent APIs, a scheduled script in version control is genuinely fine, and it is what I would recommend at that size. Managed ingestion earns its cost when connector count and connector maintenance start eating real engineering time.
- Add managed ingestion at the pain point, not before. The signal is specific: you are fixing broken extractors instead of building anything, or a source's API changed and nobody noticed for a week.
The broader argument for right-sizing — and the specific case against buying an enterprise stack for a company that does not have enterprise data — is in a modern data stack for small companies.
What is the risk of the merged vendor?
Concentration, and it deserves a clear-eyed look rather than either alarm or dismissal.
The upside is real: one vendor across movement and transformation means tighter integration, one contract, one support relationship, and a plausible story about end-to-end lineage and governance — which is genuinely hard to assemble from parts. If you were going to buy both anyway, the merger is mildly good news.
The downside is that more of your pipeline now sits under a single roadmap and a single price list, and your negotiating position is weaker when the renewal covers everything at once. Count what one company now owns: ingestion, reverse ETL, and the dominant transformation framework — and it held dbt's main open-source rival, SQLMesh, until it handed that project to the Linux Foundation. Mergers also tend to produce packaging changes; the pricing you sign today is not guaranteed to be the shape of the pricing in two years, and the January 2026 per-connection minimum is a small preview of how that goes.
The practical hedge is architectural rather than contractual. Keep transformation on open-source dbt Core, where an Apache 2.0 licence and your own SQL mean you can walk, and note that SQLMesh under neutral governance is now a credible second exit for the same SQL. Ingestion is the more replaceable layer anyway — connectors are commodity plumbing, and swapping an ingestion vendor is a project, not a rewrite. Own the modelling layer, rent the pipes.
So which should you choose?
Three straightforward answers, depending on which sentence describes you.
- You have under ten sources and no platform engineer. Managed warehouse, dbt Core, scripts or a modest managed ingestion tier. Do not buy an enterprise ingestion platform for six APIs.
- You have real connector sprawl and an engineer to run infrastructure. Airbyte self-hosted is the cost-effective choice, provided ELv2 passes your licence policy, and the merger makes an independent alternative more strategically valuable, not less.
- You have connector sprawl and no appetite to run infrastructure. Buy the managed option, and now there is a coherent argument for buying both halves from the merged vendor. Just price the renewal, not the first year.
In all three cases dbt Core is the constant. That is not vendor preference; it is that transformation logic is the part of the stack you actually own, and it should live somewhere you cannot be priced out of.
Frequently asked questions
Did Fivetran and dbt Labs merge?
Yes. The all-stock merger was announced on October 13, 2025 and completed on June 1, 2026. The combined company operates as Fivetran + dbt Labs, with George Fraser as chief executive and Tristan Handy as president. That makes any comparison treating Fivetran and dbt as rival vendors out of date.
Is Fivetran a competitor to dbt?
It never was, even before the merger. Fivetran does extract and load, moving data from sources into your warehouse. dbt does transform, modelling data already in the warehouse. They occupy adjacent stages of the same pipeline. Airbyte is the tool that actually competes with Fivetran.
Is dbt still open source?
Yes, and the licensing improved. dbt Core v2.0, built on the Rust-based Fusion engine, moved code that previously sat under the Elastic License into the dbt-core repository under Apache 2.0. It reached release candidate 1 on September 2, 2026. For teams that cannot accept non-OSI licences, that is a meaningful change.
Is Airbyte open source?
Airbyte calls it open source, but the platform is licensed under the Elastic License v2, which the Open Source Initiative has not approved. ELv2 permits self-hosting for your own use and blocks reselling it as a managed service. Community connectors are mostly MIT; Airbyte's own strategic connectors moved to ELv2 in 2023.
What is the alternative to Fivetran now?
Airbyte is the main independent option for data movement, available as a free self-hosted platform under the Elastic License v2 or as a managed cloud service. Beyond that, cloud-native ingestion services and writing your own extractors remain viable for a small number of sources, which is most small companies.
How do the pricing models differ?
Fivetran charges by consumption, priced per connection on monthly active rows, so cost tracks how much data changes. Airbyte Cloud uses volume-based credits on its Standard tier and capacity pricing on higher tiers. Self-hosted Airbyte has no licence fee but real infrastructure and engineering costs. Always model your own volumes before comparing.
Does a small company need Fivetran and dbt at all?
Often not both, and sometimes neither. With fewer than about ten sources and modest volumes, managed ingestion is a convenience rather than a necessity. dbt earns its place earlier, because version-controlled and tested transformations pay off at almost any size once more than one person depends on the numbers.
What is the risk of the merged vendor?
Concentration. Buying movement and transformation from one company simplifies procurement and integration but puts more of your pipeline under a single roadmap and a single price list. Keeping transformation on open-source dbt Core preserves an exit even if ingestion is commercial.
Get a stack you can defend to finance
Tell us your sources, your volumes, and who maintains it on a Tuesday. You'll get a specific recommendation with the licensing checked and the costs modelled against your actual data, not a vendor calculator. Scoped plan and an estimate the same business day.
Book a 30-minute intro call Prefer email? clayton@quantsolvent.co