# Open Source in the Age of SaaS: What the Fivetran-DBT Merger Means for dbt Core _By Jayashree Rajan | October 29, 2025_ Source: https://nexla.com/blog/open-source-vs-saas-fivetran-dbt-merger/ > The Fivetran–dbt merger tests the future of open source in a SaaS-dominated world. Can dbt Core stay community-driven as corporate incentives reshape the modern data stack? Here’s what’s at stake—and what comes next. ## “The Anger Is Real When Someone’s Open Source Baby Gets Murdered by a SaaS Vendor” 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. ## The Open Source Promise of dbt To understand what’s at stake, we need to remember what made dbt special. ### The Revolution That Wasn’t Supposed to Happen In 2016, data transformation was dominated by: - **Proprietary ETL tools:** Informatica, Talend, and similar platforms that cost six figures and required specialists - **Stored procedures:** SQL code living in databases with no version control, testing, or documentation - **Fragile Python scripts:** Brittle code that only their authors understood 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. ### The Community Made It Real 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. ### **The Balance: Core vs. Cloud** 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. ## The Fivetran Acquisition Reality 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: 1. **Maximize revenue from dbt Cloud:** Drive as many users as possible from free (Core) to paid (Cloud) 2. **Minimize costs on free tier:** Spend as little as possible maintaining Core 3. **Extract value from the brand:** Use dbt’s community goodwill to sell Fivetran products 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. ### The SQLMesh Wrinkle Here’s what makes this especially complicated: Fivetran already owns SQLMesh, which is actually a dbt competitor with more advanced features like: - Better incremental model handling - Virtual data environments - Integrated testing and CI/CD - Plan-based deployments 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. ## The Pattern We’ve Seen Before If this feels familiar, it should. The open source world has watched this movie many times. ### HashiCorp: The License Switch 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: The AWS Fight 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: The Gradual Closing MongoDB started fully open source (AGPL). As they built a business, they: 1. Kept the core database open (AGPL) 2. Made advanced features proprietary (Enterprise only) 3. Changed to SSPL to prevent AWS from offering it 4. Continued widening the gap between community and enterprise versions **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. ### Redis: The Latest Example 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. ## What “Open” Really Means (And Doesn’t Mean) The dbt community needs to understand what protections actually exist. ### License Types Explained **dbt Core** is under the Apache 2.0 license. This is a permissive license that allows: - Anyone to use, modify, and distribute the software - Commercial use without restriction - Forking if you disagree with the project direction - No obligation to contribute changes back What it doesn’t prevent: - The company stopping active development - New features being proprietary add-ons - The project going into maintenance mode - Community fragmentation The license protects what’s already released. It doesn’t guarantee future innovation. ### Community Governance (Or Lack Thereof) Most healthy open source projects have: - **Formal governance:** Decision-making processes independent of any single company - **Foundation support:** Neutral organization (Linux Foundation, Apache Foundation) that stewards the project - **Diverse maintainers:** Contributors from multiple organizations - **Transparent roadmap:** Public planning that community can influence 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. ### Corporate Control Realities Fivetran now controls: - **The GitHub repository:** They can accept or reject pull requests - **The release schedule:** When and what gets released - **The roadmap:** What features get built - **The brand:** “dbt” is a trademark they own - **The documentation:** What information is public vs. Cloud-exclusive - **The community spaces:** Slack, Discourse forums, etc. 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. ## The Community Response: Cautious Skepticism Reddit’s r/dataengineering and other communities are watching carefully. The sentiment ranges from worried to skeptical to openly hostile. ### The Pessimists “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 Pragmatists “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.” ### The Optimists (Rare) “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.” ### The Realists “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. ## Hedging Your Bets: A Practitioner’s Guide If you’re a dbt user—whether Core or Cloud—what should you do? ### 1. Don’t Panic (Yet) 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. ### 2. Monitor Carefully Watch for signals about Fivetran’s true intentions: Positive Signals: - Major Core releases with new features (not just bug fixes) - Continued community engagement and support - Transparent roadmap for Core development - Hiring for Core maintainer roles - Active PR review and community contributions Negative Signals: - Core releases slow to quarterly or less - “Cloud exclusive” branding on new features - Community forums getting less company engagement - Documentation increasingly focused on Cloud - Support tickets for Core deprioritized ### 3. Diversify Your Skills 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. ### 4. Build Portability Into Your Projects 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. ### 5. Consider Your Deployment Options **If you’re on dbt Cloud:** - Understand exactly what you’re paying for - Could you self-host Core if needed? - What would break if you downgraded? **If you’re on Core:** - Could you migrate to a different tool? - Are you prepared to fork if needed? - Do you have the team skills to maintain a fork? ### 6. Engage With the Community The community is dbt’s greatest strength and best protection: - Stay active in Slack, Reddit, LinkedIn discussions - Contribute packages, blog posts, and knowledge - Support initiatives to formalize governance if they emerge - Build relationships with other practitioners - Share knowledge about what Fivetran is doing A strong, vocal community makes it harder for companies to abandon open source commitments. ## The Vendor-Independent Future 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.** ### Open Standards > Open Source Tools 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. ### Data Products as Abstraction 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](https://nexla.com/nexsets/)**(or similar data product concepts) provide: - **Format independence:** Works with any file type or structure - **Protocol independence:** Batch, streaming, API—doesn’t matter - **Vendor independence:** Run on any platform - **Version independence:** Changes don’t break downstream consumers 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. ### Platform Agnostic Architecture The most resilient data architectures are designed for tool portability: **Separate concerns:** - **Storage** (S3, ADLS) is independent from - **Compute** (Spark, Trino, Snowflake) is independent from - **Catalog** (Unity, Polaris) is independent from - **Transformation** (dbt, SQLMesh) is independent from - **Orchestration** (Airflow, Dagster) Each layer can be swapped without rewriting everything else. **Use open formats:** - Store data in Parquet/Iceberg, not proprietary formats - Document in Markdown, not tool-specific formats - Version in Git, not tool-specific repositories **Minimize vendor-specific features:** - Use standard SQL over proprietary extensions - Avoid deep integration features that create lock-in - Keep customization in code you control This approach requires more discipline. You give up some convenience for portability. But when a vendor gets acquired or changes direction, you’re protected. ## How Nexla Approaches Openness 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: ### Not Open Source, But Open Architecture Nexla’s platform is proprietary. We’re not pretending otherwise. But the [data products](https://nexla.com/nexsets/) 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. ### Open Standards Support We’re built on open standards: - [Apache Iceberg](https://nexla.com/iceberg/) for table formats - Standard SQL for transformations - REST APIs for programmatic access - [Common data models](https://nexla.com/common-data-model) you define, not ones we impose If you want to run the same workload on Snowflake today and Databricks tomorrow, you can. The Nexsets work with both. ### No Artificial Feature Restrictions Some platforms have “premium connectors,” or “advanced transformations,” or “enterprise governance” as paid add-ons. We include everything in the platform. Transformations, orchestration, [governance](https://nexla.com/data-security/), quality, monitoring—it’s all there. No arbitrary feature restriction designed to force upgrades. ### Transparent Exit Path 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. ## What Happens Next with dbt Core? Let’s make some predictions: ### 6 Months Out (Q2 2026) **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. ### 12 Months Out (Q4 2026) **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. ### 24 Months Out (Q4 2027) **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 Bottom Line for Data Practitioners 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: 1. **You’re fine**: dbt skills and principles remain valuable 2. **Core will work**: Existing functionality won’t disappear 3. **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: 1. Keep using dbt (Core or Cloud) for now 2. Stay engaged with the community 3. Monitor Fivetran’s actions, not promises 4. Build portability into your projects 5. Understand alternatives without necessarily switching 6. Advocate for formal open source governance if opportunities arise 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. ## Ready to Evaluate Your Options? #### [Contact us](https://nexla.com/demo/) to systematically evaluate your current stack and provide strategic recommendations and a migration plan.