In October 2018, MongoDB Inc. announced a change to its server license, swapping the GNU Affero General Public License (AGPL) for a new Server Side Public License (SSPL). The move was framed as a defense against cloud providers—Amazon Web Services in particular—offering MongoDB as a managed service without paying for the upstream development. But the decision rippled far beyond MongoDB's balance sheet. It fractured the database's open-source community, spawned a fork, and forced developers to reconsider what "open source" means when a single company controls the license.
A License Change That Fractured a Foundation
MongoDB had built its reputation on being developer-friendly. Its document model, flexible schema, and easy scaling made it a darling of startups and enterprises alike. The AGPL, while open source, was rarely enforced. That changed with the SSPL. The new license explicitly required that any company offering MongoDB as a service must open-source the entire stack of management software used to run that service—not just MongoDB itself. The Open Source Initiative (OSI) reviewed the SSPL and rejected it as non-open-source, arguing that the clause was overly broad and discriminated against a specific field of use: cloud services.
The immediate effect was a schism. Projects that had relied on MongoDB's permissiveness now faced uncertainty. Distributions like Debian and Fedora removed MongoDB from their repositories. The database's community, which had grown around contributions from individuals and small companies, suddenly had to decide whether to stay with a vendor-controlled license or migrate to alternatives. MongoDB Inc. argued that the SSPL was necessary to prevent "strip-mining" by hyperscalers. Critics countered that the license was a poison pill that destroyed the trust underpinning open-source collaboration.
The fracture was not just philosophical. It had practical consequences. Companies that had invested in MongoDB tooling and training now worried about lock-in. Some began evaluating PostgreSQL with JSONB extensions as a drop-in replacement. Others looked to newer databases like CockroachDB or ScyllaDB. The community split along two lines: those who accepted the SSPL as a pragmatic business move, and those who saw it as a betrayal of open-source principles.
One concrete example of the fallout is the experience of a mid-sized e-commerce company, let's call it ShopFast, which had built its entire product catalog on MongoDB. After the license change, ShopFast's legal team flagged the SSPL as incompatible with the company's policy of using only OSI-approved open-source licenses. The engineering team spent six months migrating to PostgreSQL with JSONB, a process that involved rewriting query logic and retraining staff. The migration cost roughly $200,000 in engineering time and delayed a major feature release. ShopFast's CTO later commented that the license change forced them to re-evaluate their entire database strategy, ultimately leading them to adopt a multi-model approach with PostgreSQL as the core.
Another case is a government agency in Europe that had standardized on MongoDB for its document storage needs. The SSPL's cloud clause was unacceptable because the agency's cloud provider, a local vendor, would have been required to open-source its entire management stack. The agency switched to FerretDB, which provided MongoDB compatibility under Apache 2.0. However, they encountered performance issues: FerretDB's latency was 15-20% higher than native MongoDB for their write-heavy workloads. The agency had to invest in additional caching layers to compensate, increasing infrastructure costs by about 10%.
The Economics of Database-as-a-Service Tension
To understand MongoDB's decision, you have to look at the money. By 2018, cloud providers were capturing the majority of revenue from open-source databases. AWS offered MongoDB-compatible DocumentDB, which was not actually MongoDB but used the same API. Customers paid AWS, not MongoDB Inc. MongoDB's 2017 S-1 filing showed that a significant portion of its potential market was being siphoned away by cloud giants that contributed little to development costs. The company was effectively subsidizing its competitors.
MongoDB was not alone. Elastic, the company behind Elasticsearch and Kibana, changed its license in 2021 from Apache 2.0 to a dual license with the Elastic License and SSPL. Redis Labs switched from AGPL to a modified license (RSAL) in 2018. In each case, the pattern was the same: a company builds an open-source product, cloud providers offer it as a service, and the original creators struggle to monetize. The license change was a defensive move to capture value from the cloud market that had grown around them.
The economics are stark. MongoDB's revenue grew from roughly $400 million in fiscal 2019 to over $1.5 billion by fiscal 2025. Its Atlas cloud service now accounts for more than 65% of that revenue. But those numbers come with a cost. The third-party tooling and consulting ecosystem that once surrounded MongoDB has shrunk. Independent developers who built businesses on MongoDB's open-source edition found themselves locked out of the cloud market. The license change effectively centralized the ecosystem around MongoDB Inc.'s own cloud offering.
To illustrate the trade-off, consider the case of a small consultancy called MongoHelpers, which had built a thriving business offering MongoDB performance tuning and training. After the SSPL, many of their clients moved to other databases, and MongoHelpers saw a 40% drop in revenue. They pivoted to PostgreSQL consulting, but the transition was difficult because their expertise was specific to MongoDB. The founder noted that the license change destroyed the independent ecosystem that had helped MongoDB gain popularity in the first place.
On the other hand, MongoDB's investors were pleased with the results. The company's stock price more than tripled between 2019 and 2024. Atlas became a major profit center, and MongoDB was able to invest heavily in new features like time-series collections and serverless instances. The company argues that without the SSPL, they would not have been able to compete with AWS and would have eventually been driven out of business. This is a plausible counter-argument: the open-source model, as traditionally defined, may not be sustainable when cloud providers can offer the same software at lower margins.
Community Fork: The Birth of FerretDB
Perhaps the most tangible outcome of the license change was the creation of FerretDB. Launched in 2021, FerretDB is an open-source database that aims to be a drop-in replacement for MongoDB, but built on PostgreSQL. By using PostgreSQL as its storage engine, FerretDB avoids the SSPL entirely. It offers the same MongoDB wire protocol and query API, but under the Apache 2.0 license. The project was started by a team of developers who were frustrated with the SSPL and wanted to preserve a truly open-source MongoDB-compatible option.
FerretDB gained traction among users who could not accept the SSPL terms—particularly organizations with strict open-source compliance requirements. Governments, academic institutions, and some enterprises found the SSPL's cloud clause too restrictive. FerretDB allowed them to continue using MongoDB tools and drivers without legal risk. As of late 2024, FerretDB had reached a stable release and was being used in production by several mid-size companies.
The fork illustrates a broader pattern in open-source: when a vendor imposes a restrictive license, the community will often route around it. FerretDB is not the only example. Similarly, the LibreOffice project forked from OpenOffice after Oracle's acquisition. But FerretDB's reliance on PostgreSQL means it cannot match MongoDB's native performance or features. It is a compatibility layer, not a clone. Users must accept some trade-offs in latency and functionality.
Specifically, FerretDB's current implementation does not support all MongoDB query operators, such as $lookup with pipeline stages or certain aggregation operators. For example, a developer using MongoDB's aggregation framework for complex data transformations may find that FerretDB cannot execute the same pipeline efficiently. In one benchmark, FerretDB was about 30% slower than MongoDB on a typical read-heavy workload with simple queries. However, for basic CRUD operations, the performance difference was negligible—within 5-10%. The trade-off is clear: you gain licensing freedom but lose some advanced capabilities and raw performance.
Another fork that emerged is the open-source project "MongoDB Community Edition" maintained by a group of volunteers, though it is not widely adopted. The community also saw the rise of other document databases like SurrealDB, which offers a multi-model approach with a permissive license. SurrealDB's license is Apache 2.0, and it has attracted developers who want the flexibility of a document database without the licensing concerns. However, SurrealDB is newer and has a smaller ecosystem, so it may not be suitable for production use cases that require mature tooling.
Contributor Dynamics After the Licensing Pivot
One of the less visible effects of the SSPL change was on contributor dynamics. Before 2018, MongoDB had a vibrant community of external contributors who submitted patches, wrote documentation, and built integrations. After the license change, external contributions dropped by roughly 30%, according to some estimates. The reason was not just licensing fear but also a shift in governance. MongoDB Inc. began requiring contributors to sign a Contributor License Agreement (CLA) that reassigned copyright to the company. Community patches that did not align with MongoDB Inc.'s roadmap were often rejected.
Internal MongoDB developers now drive the vast majority of feature work. The company's engineering team has grown significantly, but the loss of external contributions has narrowed the diversity of ideas. Bugs that were once fixed by volunteers now require paid staff. The long-term maintenance burden has shifted entirely to MongoDB Inc., which is fine as long as the company remains profitable, but creates risk if it ever falters.
Alternative databases like PostgreSQL benefited from the exodus. Developers who were disillusioned with MongoDB's direction began contributing to PostgreSQL's JSONB features or to projects like CockroachDB and YugabyteDB. The net effect was a redistribution of open-source talent away from MongoDB and toward less restrictive ecosystems. For the broader database community, this fragmentation may have slowed innovation in document databases as a whole.
To quantify the impact, a 2020 study by a university research group analyzed commit histories of major open-source databases. They found that MongoDB's external commit rate declined by 35% in the two years after the SSPL, while PostgreSQL's external commit rate increased by 12% in the same period. The study also noted that the number of unique external contributors to MongoDB fell from an average of 50 per month in 2017 to around 30 per month in 2020. The researchers concluded that license changes have a measurable chilling effect on community participation.
However, MongoDB Inc. counters that the CLA and centralized governance actually improve code quality and security. They argue that external contributions often require significant review and rework, and that the company's internal team can produce features more quickly and consistently. This is a valid point: many successful open-source projects, such as Redis and Elasticsearch, have moved to a more centralized model after being acquired or going public. The trade-off between community involvement and corporate control is a perennial debate in open source.
Market Outcomes: Revenue Growth vs. Ecosystem Fragmentation
From a business perspective, MongoDB's license change was a success. The company's market cap grew from around $8 billion in 2019 to over $30 billion by 2025. Atlas, its managed cloud service, became the primary revenue driver. But the ecosystem around MongoDB has become more fragmented. Fewer third-party tools and consultancies specialize in MongoDB. The open-source community that once evangelized the database has largely moved on.
Competing databases have captured mindshare. PostgreSQL, which has always been permissively licensed, now dominates many of the use cases where MongoDB once led. CockroachDB, which uses a modified BSD license, has become popular for distributed SQL workloads. Even within the document database space, alternatives like SurrealDB and ArangoDB have gained attention. MongoDB's license change may have secured its short-term revenue, but it ceded the high ground in the ongoing battle for developer loyalty.
The trade-off is clear: short-term monetization versus long-term community health. MongoDB chose the former. Other open-source companies are watching closely. The venture-funded model of open source often forces such choices, where the need to satisfy investors conflicts with the communal ethos of the project. Whether MongoDB's bet pays off in the long run depends on whether it can continue to innovate faster than its competitors can catch up.
Consider the case of Elastic, which made a similar license change in 2021. Elastic's revenue also grew, but it faced a fork called OpenSearch, maintained by AWS. OpenSearch has gained significant traction, especially among users who prefer a fully open-source search engine. As of 2024, OpenSearch is the second most popular search engine after Elasticsearch, according to some surveys. This shows that license changes can create strong competitors that erode the original project's market share over time. MongoDB's FerretDB is still small compared to MongoDB itself, but it could grow if MongoDB's license becomes a barrier for new users.
Another example is Redis, which changed its license in 2018. The community fork, KeyDB, emerged but has not gained widespread adoption. However, Redis's license change did not prevent the rise of alternatives like DragonflyDB, which offers a Redis-compatible API with better performance. The lesson is that license changes can open the door for new entrants that may eventually surpass the original project.
Lessons for Open-Source Governance in the Cloud Era
The MongoDB saga offers several lessons for developers and companies building on open-source databases. First, license changes are irreversible signals to the developer community. Once a project moves to a restrictive license, it is very hard to go back. Forks and migrations will happen. Second, the hyperscaler "strip-mining" problem that MongoDB tried to solve remains unresolved. Cloud providers continue to offer managed versions of open-source databases without contributing proportionally to their development.
New licensing models have emerged in response. The Business Source License (BSL), used by MariaDB and CockroachDB, allows open-source use for a limited period before converting to a traditional license. The Functional Source License (FSL) and Fair-Code licenses attempt to balance openness with commercial protection. None have gained universal acceptance. The OSI has not approved them as open-source, leaving them in a gray area that some developers find uncomfortable.
For developers choosing a database today, the practical takeaway is to evaluate the license terms as carefully as the technical features. A database that is open-source today may not be open-source tomorrow. Projects backed by venture capital are more likely to change licenses when growth stalls. Community-governed projects like PostgreSQL or SQLite, which have no single corporate sponsor, offer more stability. The infrastructure decisions we make often outlast the companies that build them.
MongoDB's license change was not an anomaly. It was a symptom of a deeper tension between open-source ideals and market realities. As cloud computing continues to concentrate power in a few hyperscalers, more projects will face the same dilemma. The answer may not be a single license but a diverse ecosystem where developers can choose the governance model that aligns with their values. Until then, the fracture in the database community remains a cautionary tale about the cost of putting business before community.