What the Fivetran and dbt Labs Merger Means for Your ELT Vendor Strategy

Bring the leading managed-ingestion vendor together with the framework that became the default for transformation, and the marketing writes itself: one integrated path from source to warehouse-ready model, one relationship, one support line. For teams tired of stitching ingestion and transformation together, that is a genuine draw.

And there is real substance to it. When ingestion and transformation share a roadmap, the handoff between "data landed" and "data modelled" can be tighter — lineage that spans both, scheduling that understands both, fewer seams for a small data team to maintain. For a mid-market team without a platform group, that integration can be worth money.

But a buyer should separate the integration value from the single-vendor story. The first is a real engineering saving you can measure; the second is a dependency you are taking on. They are not the same thing, and the pitch tends to blur them.

The quiet effect of any merger like this is concentration: more of your data pipeline now depends on one company’s pricing, roadmap and commercial decisions. Today that company is competing for your renewal; after consolidation it competes a little less, because switching touches more of your stack at once.

That is not a reason to avoid the combined product — it is a reason to price in the dependency. The relevant questions are about bargaining power and exit, not loyalty. If this vendor raised prices 30% at renewal, how much of your stack would that touch? If you needed to leave, what exactly would you be unpicking — just ingestion, or ingestion and transformation together?

The honest read is that transformation and ingestion have very different switching costs, and the merger changes the picture for one far more than the other.

Here is the asymmetry that should shape your strategy. dbt models are SQL in version control — they describe transformations in a way that is largely portable across warehouses and, in principle, across runners. Your transformation logic is an asset you own and can move. That portability is the single biggest thing protecting you, and it is independent of who owns dbt.

Ingestion is the sticky part. Fivetran’s value is the maintained connectors — the SAP, Salesforce, NetSuite and database connectors that keep working when a source API changes. That maintenance is exactly what you are paying for, and exactly what is hard to replace, because rebuilding and maintaining connectors in-house or migrating to another ingestion tool is real work. Lock-in, where it exists, lives in the connectors, not the models.

So the protective move is to keep the transformation layer clean and portable — standard SQL, version-controlled, not dependent on vendor-only features — and to go in with eyes open on the ingestion layer, knowing that is the part with a genuine switching cost. Treat the two layers differently because their lock-in profiles are different.

Judge the combined offering on one question: does the integration save your team meaningful engineering time versus running the pieces separately? If spanning lineage, unified scheduling and a single support relationship genuinely reduce the maintenance load for your team, that is a real benefit worth paying for. If you would use the two parts the same way whether or not they shared a logo, the bundle is just a dependency with a nicer invoice.

Then apply the lock-in test to any proprietary feature the bundle offers. A capability that only exists in this combined stack, with no equivalent elsewhere, is worth adopting only if it earns its lock-in — a clear, large benefit you cannot get otherwise. Convenience features that quietly make you less portable, for a saving you could get another way, are the ones to avoid.

For most mid-market teams the sensible posture is pragmatic: use the managed connectors because maintaining them yourself is not a good use of a small team, keep dbt transformations portable, and treat the single-vendor convenience as a bonus rather than a strategy. On a Microsoft-first estate, this is also where Fabric’s native Mirroring and Dataflows Gen2 are worth comparing against a third-party ingestion spend — sometimes the ingestion you are paying a vendor for is already in the platform you own.

The merger does not demand a reaction; it demands a check. Keep your dbt transformation layer portable and version-controlled so your logic is never hostage to one runner. Know what replacing the ingestion layer would actually cost, because that is where the switching cost lives. Avoid proprietary bundle-only features unless they clearly earn their lock-in. And judge the combined stack on measured engineering-time savings, not on the single-vendor narrative.

Do that and consolidation is simply a market event you have planned around, rather than a dependency that tightened while you were not looking. The teams that get caught are the ones who adopt the convenient, vendor-only path everywhere and discover at renewal that their bargaining power went with it.