Why Fivetran’s Tobiko Data Acquisition Signals Trouble for Data Teams

Published on September 4, 2025

The Fivetran acquisition of Tobiko Data isn’t about open source innovation. It’s about commercial control.

Fivetran just spent an undisclosed sum to acquire the company behind SQLMesh and SQLGlot, positioning itself as “the only fully managed, end-to-end platform that combines data movement, transformation, and activation.” The messaging is polished, but the intent is clear: lock customers into a single vendor ecosystem where switching becomes exponentially more expensive.

Teams often discover that the real trap isn’t the initial cost, it’s realising they can’t leave without rebuilding everything. What starts as £180k annually for commodity data movement becomes a strategic dependency that’s expensive to unwind.

The stakes here aren’t just about vendor choice. They’re about maintaining the flexibility to adapt your data architecture as your business evolves, without being held hostage by commercial pricing models that punish growth.


What Fivetran Gains (And What You Lose)

The Tobiko Data acquisition represents Fivetran’s boldest move yet to create what we’re calling the “platform prison”, a comprehensive stack where leaving requires abandoning months of configuration, custom logic, and team expertise.

Here’s the strategic playbook Fivetran is executing:

Extract + Load + Transform Under One Roof Fivetran already proved that running dbt Core inside their platform appeals to customers who want “one vendor, one stack, one bill.” Now, with SQLMesh’s advanced transformation capabilities, they’re directly challenging dbt Cloud for enterprise data transformation workloads.

Open Source as Customer Acquisition SQLMesh started as an open source project that gained traction by solving real performance problems in data transformation. By acquiring Tobiko Data, Fivetran gains immediate access to this community and can gradually shift successful open source users toward their commercial platform.

Pricing Leverage Through Consolidation When you’re running Extract, Load, and Transform on a single platform, vendor negotiations become dramatically more difficult. Try switching your ETL provider when your entire transformation logic is written in their proprietary extensions and your team has spent 18 months mastering their workflow.

The pattern is predictable because we’ve seen it before: acquire promising open source technology, integrate it deeply into a commercial platform, then gradually shift pricing and feature availability to maximise revenue per customer.


Three Expensive Surprises of Platform Consolidation

Data teams often celebrate platform consolidation for its apparent simplicity, one vendor relationship, unified billing, integrated workflows. But experienced data leaders understand the true cost emerges during renewal negotiations and scaling challenges.

This mirrors the optimisation ceiling problem we discussed in our recent LinkedIn Live session on DBT and SQL Mesh. Just as teams hit architectural limits with DBT that no amount of tuning can solve, platform consolidation creates optimisation ceilings at the vendor level—constraints that become more expensive over time.

The Expansion Revenue Trap Fivetran surpassed £300 million in annual recurring revenue last year, and their growth strategy depends on increasing revenue per existing customer, not just acquiring new ones. When you’re locked into their ecosystem for Extract, Load, and Transform, they have multiple levers to increase your costs:

  • Row-based pricing that punishes data growth
  • Feature tiering that restricts capabilities unless you upgrade
  • Integration dependencies that make switching prohibitively expensive
  • Professional services that become necessary for complex transformations

The Innovation Bottleneck Platform consolidation often means innovation at the speed of the slowest component. When your transformation capabilities are tied to a vendor’s roadmap and commercial priorities, you lose the ability to adopt best-of-breed solutions as they emerge.

The Team Capability Risk Vendor-specific expertise doesn’t transfer. Engineers who become experts in Fivetran’s transformation capabilities can’t easily pivot to other tools, creating organisational dependencies that extend far beyond technology costs.


The Approach That’s Actually Working

The most resilient data architectures we see share a common principle: they’re built around interoperability and choice, not vendor convenience.

They Prioritise Open Standards Over Proprietary Platforms Instead of accepting vendor-specific extensions and workflows, they insist on solutions built around open standards that preserve switching options. When transformation logic is written in standard SQL rather than proprietary extensions, migration risk drops dramatically.

They Separate Extract, Load, and Transform Decisions Smart data teams evaluate each component independently. Your Extract/Load solution should excel at reliable data movement. Your transformation solution should excel at development experience and performance. Combining them often means accepting compromises in both.

They Demand Transparent, Predictable Pricing Row-based pricing models create unpredictable cost scaling that often catches finance teams by surprise during budget planning. Performance-based pricing aligns costs with actual infrastructure usage rather than arbitrary data volume metrics.

They Build Validation Into Migration Planning Before committing to any platform, they establish clear migration validation processes. Tools like Mirror Mode enable side-by-side testing of alternative solutions without disrupting production workflows, eliminating the “switching fear” that traps teams in suboptimal arrangements.


The Market Response: Why Open Alternatives Matter More Than Ever

Fivetran’s acquisition of Tobiko Data demonstrates exactly why the market needs truly independent, open alternatives. When promising open source projects get absorbed into commercial platforms, innovation gets redirected toward revenue maximisation rather than user value.

This consolidation creates three immediate risks for data teams:

  • Reduced Innovation Competition: Fewer independent solutions mean slower innovation cycles and less pressure on vendors to improve pricing or capabilities
  • Commercial Feature Gating: Open source features may gradually move behind commercial licenses or be deprecated in favour of platform-specific alternatives
  • Community Fragmentation: Developer communities often split when projects transition from independent open source to commercial control

The solution isn’t to avoid modern data tools, it’s to choose solutions that preserve your flexibility and maintain genuine open source foundations that can’t be commercialised away from users.


FAQs About Platform Consolidation vs. Best-of-Breed Approaches

How do you evaluate whether platform consolidation makes sense for your team?

Consider your data complexity, team size, and switching tolerance. Teams with straightforward data workflows and limited engineering capacity often benefit from platform consolidation initially. But as data complexity grows and costs scale, the trade-offs usually shift toward favouring independent, interoperable solutions that preserve choice.

What’s the real cost difference between consolidated platforms and best-of-breed approaches?

Consolidated platforms typically offer lower initial costs and faster time-to-value. Best-of-breed approaches require more initial integration work but usually deliver better long-term cost control and innovation flexibility. The break-even point often occurs around £200-400k in annual data tooling spend, where performance-based pricing and reduced vendor dependency create meaningful savings.

How can you reduce switching risk when evaluating new data platforms?

The key is validation before commitment. Modern solutions like Mirror Mode enable you to test alternative approaches alongside your production systems, comparing performance, costs, and team productivity without disrupting existing workflows. This validation period should last long enough to see real data volumes and use case diversity, typically 30-90 days depending on your data complexity.

Should teams avoid Fivetran entirely after this acquisition?

Not necessarily. Fivetran remains a capable ETL solution for many use cases. The key is entering any vendor relationship with clear visibility into switching costs and preservation of choice. Avoid vendor-specific extensions, maintain transformation logic in portable formats, and regularly evaluate alternative solutions to ensure you’re not gradually locked into arrangements that no longer serve your interests.


From Platform Dependency to Strategic Choice

The Fivetran-Tobiko Data acquisition represents more than just another consolidation play, it’s a preview of how commercial platforms will increasingly absorb promising open source innovations to strengthen their competitive moats.

For data teams, the lesson is clear: preserve your strategic flexibility. Choose solutions that respect open standards, avoid vendor-specific extensions, and maintain clear exit strategies. When platforms consolidate around commercial control rather than user value, teams with the most options build the most resilient architectures.

Your data infrastructure should serve your business strategy, not constrain it.

Download the ETL Escape Plan →

Get our comprehensive guide to evaluating ETL alternatives, including cost comparison frameworks, migration risk assessment, and validation strategies that eliminate switching anxiety.

#Blog

Data Leaders Digest

Stay up to date with the latest news and insights for data leaders.