That comment from Reddit’s r/dataengineering community captures the raw emotion around the Fivetran-dbt merger. It’s not about financial details or product roadmaps. It’s about something deeper: the fate of an open source project that changed thousands of careers and fundamentally transformed how data teams work.
dbt Core is more than software. It’s a movement. It brought software engineering best practices to data transformation. It created a thriving community of practitioners who learned from each other, built on each other’s work, and evangelized a better way.
Now that movement’s future is in the hands of Fivetran—a company with zero history in open source and every incentive to drive users toward their paid products.
Should the community be worried? Let’s examine what history teaches us about open source projects after corporate acquisition, what Fivetran’s incentives actually are, and what practitioners can do to protect the tools and communities they’ve built.
To understand what’s at stake, we need to remember what made dbt special.
In 2016, data transformation was dominated by:
Then Fishtown Analytics (later dbt Labs) released dbt—a simple but radical idea: treat data transformation like software development.
Version control your transformations in Git. Test your models automatically. Document everything in code. Modularize with reusable components. Deploy through CI/CD pipelines.
dbt Core, the open source foundation, became a phenomenon because of its community:
Thousands of packages: Reusable transformations for common tasks, built and shared freely
Active Slack community: 50,000+ practitioners helping each other debug, optimize, and learn
Conference ecosystem: Coalesce became one of the data industry’s premier events
Career transformation: “Analytics Engineer” emerged as a new role, with dbt skills in high demand
Educational content: Hundreds of blog posts, tutorials, and courses teaching dbt
This wasn’t a company giving away software to drive services revenue. This was a genuine community building something together.
dbt Labs built a business model that seemed sustainable:
dbt Core: Free, open source, self-hosted. You handle infrastructure, scheduling, and orchestration.
dbt Cloud: Paid SaaS with scheduling, IDE, documentation hosting, observability, and enterprise features.
Many practitioners used Core for learning or small projects, then convinced their companies to pay for Cloud for production workloads. The transition felt natural, not forced.
dbt Labs raised over $400M at a $4.2B valuation. The open source approach seemed to be working—for the company and the community.
Now Fivetran owns dbt Labs. The companies promise to keep dbt Core open source “indefinitely” and “actively maintain” it. They even highlight Fivetran’s contributions—over 100 OSS dbt packages, 5 full-time staff on open source.
So what’s the problem?
Corporate Incentives Are Crystal Clear
Fivetran is a for-profit SaaS company. They need to justify their valuation to investors who expect growth and eventually an IPO or acquisition at even higher valuations.
Their incentives are:
These aren’t criticisms. They’re just how businesses work. But they’re fundamentally in tension with what made dbt Core great: an active, innovative open source project that served users first and monetization second.
“Maintain” ≠ “Innovate”
Fivetran promises to “actively maintain” dbt Core. But what does “maintain” mean?
In open source, there’s a spectrum:
Active Development: Regular feature releases, performance improvements, expanding capabilities
Maintenance Mode: Security patches, bug fixes, dependency updates
Life Support: Critical security fixes only Abandonware: No updates at all
Fivetran promises “maintenance.” They don’t promise active development or feature parity with Cloud.
The community fear, expressed repeatedly on Reddit: Core will stagnate while Cloud gets all the innovation.
New features will be “dbt Cloud exclusive.” The free tier will work, but barely evolve. Over time, the gap between Core and Cloud will widen until using Core in production becomes impractical.
Here’s what makes this especially complicated: Fivetran already owns SQLMesh, which is actually a dbt competitor with more advanced features like:
If Fivetran wants transformation technology, they have it. So why acquire dbt?
They bought the community and the brand.
80-90% of Fivetran customers already use dbt. Acquiring dbt Labs wasn’t about technology—it was about controlling the ecosystem and monetizing the user base.
This raises an uncomfortable question: What happens to SQLMesh? And what happens to dbt Core when Fivetran has two transformation frameworks?
The most likely outcome: SQLMesh technology gets merged into dbt Cloud (paid tier), while dbt Core gets minimal investment.
If this feels familiar, it should. The open source world has watched this movie many times.
For years, HashiCorp offered Terraform and Vault under the Mozilla Public License (MPL). These tools became infrastructure standards with massive communities.
Then in August 2023, HashiCorp changed Terraform to the Business Source License (BSL)—prohibiting competitive use. The community was furious.
The Result: OpenTofu forked Terraform within weeks. The Linux Foundation adopted it. Many enterprises migrated away from HashiCorp.
The Lesson: Even established open source projects can have their licenses changed when corporate priorities shift.
Elastic (Elasticsearch, Kibana) was fully open source under Apache 2.0. Then Amazon launched Amazon Elasticsearch Service—essentially offering Elastic’s software as a managed service without paying Elastic.
Elastic’s response? Change the license to Server Side Public License (SSPL), which prevents cloud providers from offering it as a service.
The Result: AWS forked Elasticsearch into OpenSearch. The community fractured. Enterprises had to choose sides.
The Lesson: When open source projects face competition from cloud giants, they often restrict licenses—hurting the community caught in the middle.
MongoDB started fully open source (AGPL). As they built a business, they:
The Result: The community edition works, but serious production use requires Enterprise. Open source in name more than in practice.
The Lesson: “Open source” can become a marketing term for a deliberately limited version designed to drive paid upgrades.
In March 2024, Redis Labs changed Redis from BSD to a dual-license model (SSPL and SSPLv1). Core features stay open, but many modules are now proprietary.
The Result: Linux Foundation forked Redis into Valkey. Cloud providers rallied around the fork.The ecosystem split.
The Lesson: Even projects with decades of history can see their open source foundations eroded when corporate pressures mount.
The dbt community needs to understand what protections actually exist.
dbt Core is under the Apache 2.0 license. This is a permissive license that allows:
What it doesn’t prevent:
The license protects what’s already released. It doesn’t guarantee future innovation.
Most healthy open source projects have:
dbt has none of this. It’s a company-controlled open source project. All decisions flow through dbt Labs (now Fivetran).
This isn’t inherently bad—many successful projects operate this way. But it means the community has no formal power. If Fivetran decides Core gets minimal investment, the community can’t overrule them.
Fivetran now controls:
The community can fork the code (it’s Apache 2.0). But they can’t fork the brand, the community spaces, or the ecosystem integration that makes dbt valuable.
Reddit’s r/dataengineering and other communities are watching carefully. The sentiment ranges from worried to skeptical to openly hostile.
“Core is gonna stay unchanged while Cloud keeps gaining new features. Eventually, it will be end-of-life.”
“The anger is real when someone’s open source baby gets murdered by a SaaS vendor.”
“Fivetran has zero history with open source. This is just them buying market share and slowly killing the free tier.”
“The Apache 2.0 license protects us. If they try anything shady, we fork it.”
“dbt Core has over 2,000 forks on GitHub already. The community will keep it alive if needed.”
“Look, most people were already using dbt Cloud in production anyway. Core was for learning and small projects.”
“Fivetran has contributed 100+ dbt packages. Maybe they actually care about open source?”
“Better integration between ingestion and transformation could be good for everyone.”
“The market is consolidating. This was inevitable.”
“Watch what they do, not what they say. If Core gets a major feature release in the next 6 months, maybe they’re serious. If it doesn’t, we have our answer.”
This is the community taking a “trust but verify” stance. They’re not rioting, but they’re not buying the promises either.
If you’re a dbt user—whether Core or Cloud—what should you do?
The merger just closed. Regulatory approval is still pending. Both companies operate independently for now.
Your dbt projects will continue working. The skills you’ve built remain valuable. Don’t make hasty decisions based on fear.
Watch for signals about Fivetran’s true intentions:
Positive Signals:
Negative Signals:
Don’t be 100% dependent on dbt-specific knowledge:
Learn the underlying principles: Dimensional modeling, SQL optimization, data testing, documentation practices. These transfer to any tool.
Explore alternatives: SQLMesh (ironic), Dataform, or emerging transformation frameworks. You don’t need to switch, but understanding the landscape helps.
Master the platform: dbt is a layer on top of your data warehouse. Deep Snowflake, Databricks, or BigQuery skills give you optionality.
Make your dbt projects less dbt-specific:
Modular transformations: Keep complex logic in small, reusable models
Minimal macro use: The more custom macros, the harder to migrate
Standard SQL: Avoid warehouse-specific dialect when possible
Tests as documentation: Your tests document business logic in a portable way
Version everything: Git history is platform-independent
If you ever need to move to a different transformation tool, you want your logic well-documented and modular.
If you’re on dbt Cloud:
If you’re on Core:
The community is dbt’s greatest strength and best protection:
A strong, vocal community makes it harder for companies to abandon open source commitments.
The dbt-Fivetran situation highlights a broader principle: building on open source doesn’t protect you from vendor control if that open source is company-controlled.
What really matters isn’t whether your tool is open source. It’s whether your data architecture is built on open, interoperable standards.
SQL: Standardized query language that works across platforms
Apache Iceberg: Open table format for data lakes
Parquet/ORC: Open columnar file formats
REST APIs: Standardized interfaces
Git: Version control is platform-independent
If your transformations are good SQL in version control, you can run them anywhere. The specific tool (dbt, SQLMesh, Dataform) is less critical.
Here’s a more robust approach: build with data products, not tool-specific implementations.
Instead of Fivetran-specific schemas or dbt-specific models, create an abstraction layer:
Nexsets (or similar data product concepts) provide:
This abstraction layer makes your actual tooling choices less critical. Switch from Fivetran to Airbyte? Your data products don’t change. Move from dbt to SQLMesh? Same models, different execution engine.
The most resilient data architectures are designed for tool portability:
Separate concerns:
Each layer can be swapped without rewriting everything else.
Use open formats:
Minimize vendor-specific features:
This approach requires more discipline. You give up some convenience for portability. But when a vendor gets acquired or changes direction, you’re protected.
Full disclosure: this is a Nexla blog, so let’s be transparent about our approach.
We face the same tension every data platform faces: be valuable enough that customers pay, but open enough that they’re not locked in.
Here’s how we think about it:
Nexla’s platform is proprietary. We’re not pretending otherwise.
But the data products we create (Nexsets) are vendor-independent. They’re not “Nexla format” data—they’re standard formats (Parquet, JSON, CSV) with metadata that works anywhere.
If you build 100 Nexsets in Nexla and then decide to move to a different platform, your data products remain usable. You don’t have to rewrite your downstream analytics because we didn’t lock you into proprietary schemas.
We’re built on open standards:
If you want to run the same workload on Snowflake today and Databricks tomorrow, you can. The Nexsets work with both.
Some platforms have “premium connectors,” or “advanced transformations,” or “enterprise governance” as paid add-ons.
We include everything in the platform. Transformations, orchestration, governance, quality, monitoring—it’s all there. No arbitrary feature restriction designed to force upgrades.
We provide tooling to export your Nexsets, configuration, and transformations. If you leave, you take your work with you.
This isn’t altruism—it’s confidence. If we’re building value, you’ll stay because we’re useful, not because switching is impossible.
Let’s make some predictions:
dbt Core will get maintenance releases: Bug fixes, security patches, dependency updates. This will be held up as evidence of Fivetran’s commitment.
dbt Cloud will get new features: Probably around AI integration, maybe improved orchestration. These will be “Cloud exclusive.”
Community will wait and watch: Too early to judge. Some experimentation with alternatives begins quietly.
Core vs. Cloud gap widens: Several “game changing” features announced for Cloud. Core gets them 6-12 months later, if at all.
First “migration to Cloud” pressure: Fivetran sales will start pushing combined Fivetran + dbt Cloud deals hard. Pricing incentives to bundle.
Alternative tools gain traction: SQLMesh, Dataform, and new entrants start winning deals from teams concerned about Core’s future.
Core is officially in maintenance mode: Annual releases, security patches only. All innovation in Cloud.
Fork discussions get serious: Community debates whether to fork Core and create independent governance.
Enterprises reassess: Companies using Core in production either upgrade to Cloud or migrate to alternatives.
This is speculation, but it’s informed speculation based on decades of similar situations.
The Fivetran-dbt merger puts dbt Core’s future in question. Not immediately, not catastrophically, but meaningfully.
If you’re building your career on dbt:
✅ You’re fine: dbt skills and principles remain valuable ✅ Core will work: Existing functionality won’t disappear ✅ The community persists: 50,000+ practitioners aren’t going anywhere
But also:
⚠️ Active development may slow: Core could stagnate ⚠️ Cloud pressure will increase: Monetization incentives are clear ⚠️ Alternatives will emerge: Market abhors a vacuum
What you should do:
And remember: The principles matter more than the tools. Version control, testing, documentation, modularity—these work in any transformation framework.
dbt taught a generation of data practitioners to work like software engineers. That lesson endures regardless of what happens to dbt Core.
The tool might change. The movement won’t.
In the News: Watch Nexla CEO Saket Saurabh analyze the Fivetran-dbt Labs merger with John Furrier on theCUBE + NYSE Wired, exploring its strategic impact on the evolving data ecosystem.
Fivetran and Nexla are leading data integration platforms, but they take different approaches. Learn how they compare on features, deployment, and governance to find the right fit for your data strategy.
The modern data stack has failed. The Fivetran–dbt merger highlights tool sprawl, rising costs, and integration complexity, forcing data leaders to rethink their infrastructure strategy. Choose wisely.
Webinar 
