Here is the most important thing to understand about MongoDB in 2026: it is the project that started the modern license war, and it did so by moving away from a recognized open-source license. In October 2018 MongoDB abandoned the AGPL — a license the Open Source Initiative approves — for the Server Side Public License, a license the OSI explicitly rejects. Unlike Redis, Terraform, or Elasticsearch, MongoDB never got a community code fork. Instead it got something cleverer: FerretDB, an Apache-2.0 layer that speaks the MongoDB wire protocol and stores your data in PostgreSQL. This is the story of the SSPL, why it matters, and what your options are.
For a decade MongoDB was the default document database, the thing teams reached for when they wanted flexible schemas and horizontal scale without the rigidity of a relational backend. It powered startups, enterprises, and cloud services. Then it changed its license, cloud providers built their own MongoDB-compatible services to avoid it, Linux distributions removed it, and an open-source community built a drop-in alternative that does not contain a line of MongoDB code. The license that was meant to protect MongoDB's business may have done more to fragment its ecosystem than to defend it.
This review covers what MongoDB is, the AGPL years, the 2018 SSPL switch, exactly what the SSPL forbids, why the OSI rejects it, what Debian and the CNCF did, the Amazon and Microsoft responses, how FerretDB works under the hood, its compatibility gaps, real self-hosting and managed costs, where your documents actually live, and an honest verdict for a sovereignty-minded operator.
1. What MongoDB Actually Is
MongoDB is a document database. Instead of rows and tables, it stores JSON-like documents in collections, with a flexible schema that lets you evolve your data shape without migrations in the traditional sense. Its query language is expressive — rich filtering, aggregation pipelines, geospatial queries, and full-text search — and its drivers exist for essentially every programming language. For teams that outgrew the strictness of SQL or wanted to model hierarchical data naturally, MongoDB was the obvious choice, and it became synonymous with "NoSQL" for a generation of developers.
The core job MongoDB takes is "store my semi-structured data and let me query it like I think about it." It scales through sharding — splitting data across nodes by a shard key — and replicates through replica sets for high availability. It is, by deployment count, one of the most widely used databases in the world, and its influence on how modern applications model data is hard to overstate.
2. The AGPL Years (2009–2018)
For its first nine years MongoDB shipped under the GNU Affero General Public License, version 3. The AGPL is a strong copyleft license and, crucially, an OSI-approved open-source license. Its defining clause is the "network copyleft": if you modify AGPL software and let users interact with it over a network, you must offer them the modified source. For a database, that meant anyone running a modified MongoDB as a service had to share their changes. The AGPL was already a deterrent to cloud providers reselling a modified MongoDB, but it did not stop them from reselling the unmodified software.
This is the quiet setup. The AGPL protected modified versions but not the unmodified one, and cloud providers — AWS chief among them — began offering MongoDB-compatible and MongoDB-branded services without contributing back in the way MongoDB Inc. wanted. The company's response was not to strengthen the AGPL but to replace it with something broader and, from the open-source community's perspective, more dangerous.
3. October 2018: The SSPL Switch
On October 16, 2018, MongoDB announced it would license all future versions under the Server Side Public License, effective with version 4.0. The SSPL was MongoDB's own invention, written specifically to close the gap the AGPL left open. Its headline clause: if you offer the software to third parties as a service, you must release the complete source code of not just the database but the entire service stack that makes it available — management layers, APIs, orchestration, monitoring, and deployment tooling. The AGPL required you to share your modifications; the SSPL requires you to share your whole service.
The intent was precise. MongoDB Inc. wanted to stop cloud providers from taking the database, wrapping it in a managed offering, and capturing the revenue without a commercial agreement. By demanding that the entire service be open-sourced, the SSPL made it impractical for a hyperscaler to offer MongoDB-as-a-service without either licensing from MongoDB Inc. or rebuilding the surrounding stack. For an ordinary application developer connecting MongoDB to their own app, internal use remained fully permitted. The restriction was aimed squarely at competitors offering MongoDB as a hosted product.
4. Why the OSI Rejects the SSPL
The Open Source Initiative reviewed the SSPL and declined to approve it as open source. The core objection is that the SSPL's reach extends far beyond the licensed software itself. By requiring disclosure of the "corresponding source" of the entire service through which the software is made available, the SSPL imposes obligations on code and systems that have nothing to do with MongoDB. A traditional open-source license governs the work it covers; the SSPL governs the surrounding infrastructure. That breadth, the OSI argued, violates the principle that open-source licenses should not place restrictions on other software. MongoDB's response was essentially that the SSPL is "source available," not "open source," and never claimed OSI approval — a candid framing that nonetheless left the community without an OSI-blessed MongoDB.
5. The Practical Fallout: Distributions Drop MongoDB
The non-open status of the SSPL had concrete consequences that had nothing to do with cloud providers. Linux distributions, which have policies against shipping non-open or ambiguous-license software in their main repositories, began removing MongoDB. Debian dropped it after version 11; Ubuntu only carries it up to 22.04 via apt, and newer releases require third-party sources. The CNCF, which requires OSI-approved licenses for hosted projects, will not accept SSPL software. Compliance and security tooling vendors grew cautious about ingesting MongoDB into their pipelines. None of this made self-hosting MongoDB illegal — you can still download and run it freely for internal use — but the surrounding ecosystem's willingness to package, certify, and recommend it measurably declined. That erosion is the quiet cost of the SSPL that rarely makes the headlines.
6. The Cloud Provider Response: Compatible, Not Licensed
The SSPL was meant to force cloud providers to either pay or stop. What actually happened was more interesting: they built compatible services rather than licensing MongoDB. Amazon launched DocumentDB, a MongoDB-compatible database that speaks the wire protocol but is not MongoDB under the hood. Microsoft's Azure Cosmos DB for MongoDB does the same. Google offered a MongoDB-compatible API on its Datastore. None of these run MongoDB's SSPL code; they implement the protocol independently. The SSPL's clause about offering "the software" as a service did not forbid offering a compatible implementation, so the hyperscalers simply built their own. MongoDB Inc.'s attempt to capture that revenue thus pushed the largest cloud customers onto rival, MongoDB-compatible engines — a strategic outcome the company may not have intended.
7. Why No Code Fork Appeared
A natural question: why did MongoDB not get a community code fork the way Terraform got OpenTofu or Elasticsearch got OpenSearch? The answer lies in the license direction. Redis, Terraform, and Elasticsearch moved from OSI licenses to restrictive ones, leaving a last-open version that a foundation could fork. MongoDB moved from an OSI license (AGPL) to a restrictive one (SSPL) with no open version to return to — every version going forward was SSPL. Forking SSPL code would just produce more SSPL code, which solves nothing for teams wanting open licensing. So the community's energy went not into forking but into reimplementation: build something that speaks MongoDB's protocol under a permissive license. That is exactly what FerretDB is.
8. FerretDB: The MongoDB API Without the Legal Migraine
FerretDB is an open-source, Apache-2.0-licensed database that speaks the MongoDB wire protocol and translates it into queries against a real relational database — PostgreSQL. Your application uses the standard MongoDB driver — pymongo, the Node driver, the Go driver — connects to FerretDB using the same
mongodb:// connection string format, and issues the same CRUD operations and aggregation commands. Underneath, FerretDB converts those into SQL against PostgreSQL. Your app thinks it is talking to MongoDB; it is actually talking to Postgres. The pitch is freedom: the MongoDB ecosystem and ergonomics without the SSPL.
FerretDB is not a fork of MongoDB. It contains no MongoDB source. It is a protocol-compatible reimplementation, which is precisely why it is legally clean under the SSPL. As of its 2.x line, FerretDB is built on Microsoft's open-sourced DocumentDB PostgreSQL extension, which adds a native BSON type to Postgres and dramatically improved performance over the 1.x architecture — claims of up to 20x faster for certain workloads powered by the same engine behind Azure Cosmos DB for MongoDB. The project carries roughly 11,000 GitHub stars and is free with no paid tier, though a managed FerretDB Cloud launched in August 2025 on AWS.
9. How FerretDB Works Under the Hood
Understanding FerretDB means understanding the translation layer. When your driver sends a MongoDB insert, FerretDB maps the document into PostgreSQL rows, using the DocumentDB extension's BSON type to preserve document structure. A MongoDB query becomes a SQL
SELECT with JSON-path predicates. An aggregation pipeline becomes a series of SQL operations, though not every pipeline stage maps cleanly. Indexes you create via the Mongo API become Postgres indexes. Transactions become Postgres transactions. The result is that for the majority of CRUD and common-query workloads, your application code does not change at all — you swap the connection string and point it at FerretDB.
The magic and the limitation are the same fact: it is a translation layer. Every operation pays a translation cost that native MongoDB does not, and some MongoDB features do not translate to Postgres semantics at all. For typical self-hosted workloads the overhead is usually unnoticeable, but at millions of writes per minute the translation tax becomes real. FerretDB makes the most sense as a migration path away from MongoDB and as a way to keep Mongo ergonomics on infrastructure you already run, not necessarily as a drop-in for the most demanding native workloads.
10. Compatibility Gaps You Must Test
Honesty requires listing what FerretDB does not do. Advanced features have gaps: change streams, which let applications react to data changes in real time, are not fully supported. Kerberos and LDAP authentication methods are incomplete. Some aggregation pipeline operators do not translate cleanly and may require rewriting. Certain MongoDB-specific behaviors around geospatial queries and full-text search are "getting there" but not perfect. The FerretDB team publishes a compatibility matrix, and the responsible move before adopting it is to run your application's query patterns against that matrix. For many teams the gaps are irrelevant; for a few they are disqualifying. The license freedom is real, but it is not free of trade-offs.
11. FerretDB 2.0 and the DocumentDB Engine
The 2.x line was the inflection point for FerretDB. By re-platforming onto Microsoft's open-sourced DocumentDB PostgreSQL extension — released under MIT in early 2025 — FerretDB gained a native BSON type inside Postgres, removing much of the JSON-marshaling overhead that plagued 1.x. The performance improvement, attributed to the same engine that powers Azure Cosmos DB for MongoDB, is the reason FerretDB 2.0 is taken seriously as more than a stopgap. FerretDB v2 also dropped the earlier MySQL and SQLite backends in favor of a focused Postgres-plus-DocumentDB architecture, simplifying the project and concentrating engineering on the path that performs.
12. Running FerretDB in Practice
Deployment is straightforward. You run a Postgres instance with the DocumentDB extension baked in — plain Postgres will not work for v2; you need the
postgres-documentdb image — and a FerretDB container pointed at it. A typical Docker Compose stacks the two, exposes port 27017, and your app connects exactly as it would to real MongoDB. The operational burden is moderate: you are really managing Postgres, which most teams already know how to do, plus a small container for FerretDB itself. Backups are just Postgres backups. Replication is just Postgres replication. This is a genuine advantage — you inherit the reliability, tooling, and ecosystem of the most battle-tested open-source database on the planet, wrapped in a MongoDB costume.
13. Where Your Documents Actually Live
Data sovereignty for a document database is about who holds your data and under what license the software that stores it runs. With self-hosted MongoDB Community Server, your documents live in your own storage under your own control, but the software is SSPL — source available, not OSI open. With FerretDB, your documents live in PostgreSQL, the most established open-source database there is, under Apache 2.0 for the FerretDB layer and PostgreSQL's permissive license for the store. For a sovereignty-minded operator, the difference is not where the bytes sit — both can be on your hardware — but what license governs the system and whether you can audit, modify, and redistribute it without restriction. FerretDB wins that comparison decisively.
14. Real Self-Hosting Costs
Self-hosting MongoDB Community Server is cheap on compute: a small production replica set runs on a few modest VMs, perhaps $10–$20 per month for a small deployment, more as you scale with shards. There is no license fee for Community Server for internal use. The cost is operational: replica sets, sharding, backups, and security hardening all require expertise. FerretDB's cost is the underlying Postgres instance — roughly $5–$50 per month depending on scale — plus a small container, with no FerretDB paid tier currently required. The economic story is that FerretDB does not add a license cost; it shifts your database spend to Postgres, which most teams already pay for anyway. For teams migrating off MongoDB for licensing reasons, the TCO is often lower because they consolidate onto Postgres infrastructure they already run.
15. Managed Alternatives and the Atlas Question
MongoDB Inc.'s own managed offering, Atlas, is excellent and removes operational burden entirely — but it is the commercial product the SSPL was designed to protect, and using it means accepting MongoDB Inc.'s pricing and terms rather than escaping the license question. FerretDB Cloud, launched in 2025 on AWS, offers a managed FerretDB for teams that want Postgres durability without running it themselves. AWS DocumentDB and Azure Cosmos DB for MongoDB offer managed MongoDB-compatible services that avoid the SSPL entirely by not running MongoDB. Each managed path trades control for convenience; the self-hosted FerretDB path trades convenience for control and license cleanliness. The right choice depends on whether your team has the operational maturity to run Postgres well.
16. The AGPL-to-SSPL Move in Context
MongoDB's 2018 switch is the ur-example of the modern license controversy, and it is worth framing against the later wave. Redis, Terraform, and Elasticsearch moved from OSI licenses to restrictive ones and got forks. MongoDB moved from one copyleft license to a broader, non-OSI one and got a reimplementation. CockroachDB moved to BSL and then to private source and got neither a fork nor a viable reimplementation. The throughline is that when a vendor tightens a license, the community responds in the way the license permits: fork the last open version, or rebuild the protocol. MongoDB's case proved that the protocol-rebuild path is viable and that a well-designed wire protocol is itself a kind of moat — one the community can cross without touching the licensed code.
17. Is the SSPL Actually a Problem for You?
For many users, the SSPL is a non-event. If you are an application developer connecting MongoDB to your own app, or a small team running it internally, the SSPL's restrictions do not touch you — internal use is permitted. The problem bites if you are a cloud provider offering MongoDB as a service, a vendor bundling MongoDB into a competing product, or an organization with compliance regimes that treat non-OSI licenses as ineligible. The gray zone is "internal tooling offered to others" — the SSPL's wording about providing the software to third parties can read broadly, and nobody wants to inhabit a legal gray zone. The safe read is: if you just use MongoDB, you are fine; if you distribute or service it, read the license with counsel.
18. The Compatibility Lie Nobody Tells You
A subtle point often missed: MongoDB-compatible services are not MongoDB. Amazon DocumentDB and Azure Cosmos DB for MongoDB implement a subset of the wire protocol, and over time they drift from MongoDB's feature set. Applications that lean on the latest MongoDB features can break against a compatible service. This is the same risk FerretDB carries, though FerretDB's explicit goal is fidelity rather than a divergent product. The lesson is that "MongoDB-compatible" is a spectrum, not a binary, and the compatibility matrix is your friend. Do not assume a compatible engine is a drop-in until you have tested your actual query patterns against it.
19. Migration: From MongoDB to FerretDB
Migrating to FerretDB is, for compatible workloads, a connection-string swap. Because FerretDB speaks the Mongo wire protocol, most applications connect unchanged. The work is in validation: run your test suite against FerretDB, check the compatibility matrix for the features you use, and verify aggregation pipelines and indexes behave. For data migration, you use
mongodump/mongorestore or write a small script that reads from MongoDB and writes through the FerretDB connection. The heaviest migrations are those that depend on unsupported features — change streams, certain auth methods — which may require application changes. The honest framing: FerretDB is a low-effort escape from the SSPL for most teams and a rewrite for a few.
20. The Community and Ecosystem
MongoDB's community is enormous and remains so; the mongodb/mongo repository carries tens of thousands of stars and daily commits, and the ecosystem of drivers, ORMs, and tutorials is unmatched. FerretDB's community is younger but growing, with an active project and a clear value proposition in a post-SSPL world. The split is not a death for either side — MongoDB Inc. continues to ship a powerful database and a successful cloud — but the ecosystem that was once unified around one open database is now partitioned between an SSPL core and an Apache-2.0 compatible layer. That partitioning is the lasting legacy of the 2018 decision.
21. Security and Compliance Considerations
For regulated industries, the SSPL's non-OSI status is often a procurement blocker. Compliance tooling vendors, distribution maintainers, and standards bodies that require OSI-approved licenses treat SSPL as ineligible, which can surface late in a security review. FerretDB, being Apache 2.0 over PostgreSQL, sails through those reviews. PostgreSQL's own security track record is exemplary, and FerretDB inherits the scrutiny that Postgres receives. The compliance argument alone pushes many enterprise teams toward FerretDB even when the license restriction would not legally bind them — the friction of explaining SSPL to an auditor is its own cost.
22. Performance: The Translation Tax
We should be honest about performance. FerretDB translates Mongo operations into Postgres operations, and that translation is not free. For read-heavy, typical workloads the overhead is usually negligible and the DocumentDB engine's native BSON support keeps it close to native Mongo. For write-heavy, high-throughput workloads — millions of inserts per minute — the translation and the underlying relational overhead can become visible. Native MongoDB, engineered as a purpose-built document store, will generally win on raw document throughput. The practical advice: benchmark your actual workload, do not assume, and remember that for the vast majority of self-hosted applications the difference is imperceptible.
23. When to Choose MongoDB Anyway
There are good reasons to stay on MongoDB Community Server or Atlas. If you depend on change streams, Kerberos/LDAP auth, or the newest MongoDB features, FerretDB's gaps may be disqualifying. If your compliance regime accepts SSPL, or if internal use is all you need, the license is a non-issue. If you want the deepest ecosystem, the most drivers, and the most Stack Overflow answers, MongoDB is still the center of gravity. And Atlas remains the easiest path to a managed document database. The SSPL is a factor, not a verdict; for some teams it is irrelevant.
24. When to Choose FerretDB
Choose FerretDB when you want MongoDB ergonomics without the SSPL, when license cleanliness is a procurement or compliance requirement, when you already run PostgreSQL and want to consolidate, when you are migrating off MongoDB for licensing reasons, or when you are starting fresh and prefer an OSI-approved stack. It is the right call for teams that use MongoDB's common feature set — CRUD, indexing, most aggregation, transactions — and do not need its bleeding-edge or enterprise features. For those teams, FerretDB delivers the Mongo experience on top of the most trusted open database in the world.
25. Getting Started With FerretDB
Spin up FerretDB with Docker Compose: a
postgres-documentdb service for the store and a ferretdb service pointed at it via FERRETDB_POSTGRESQL_URL, exposing 27017. Point your application's Mongo driver at mongodb://localhost:27017 and your existing code works. Create collections, insert documents, run aggregations exactly as you would against MongoDB. For production, size the Postgres instance for your workload, enable replication and backups as you would for any Postgres deployment, and keep the FerretDB container lightweight. The only new habit is remembering that your data lives in Postgres, so your Postgres tuning and backup discipline are now your Mongo tuning and backup discipline.
26. Reading the License, Not the Headline
As with every project in this license wave, the discipline that matters is verifying the license against the project's LICENSE file, not a blog post. MongoDB Community Server is SSPL-1.0; FerretDB is Apache 2.0; PostgreSQL is permissive. These facts are checkable in the repositories and they change your compliance and cost calculus. The SSPL is not going away, and MongoDB Inc. shows no sign of returning to the AGPL, so the practical question is not "will MongoDB reopen?" but "given that it will not, what is my path?" FerretDB is the most complete answer the open community has built.
27. The Broader Pattern
MongoDB is the beginning of the story this blog has been tracing. It invented the SSPL in 2018, years before Redis, Terraform, and Elasticsearch made license changes fashionable. Its outcome — no fork, but a protocol-compatible reimplementation — is a distinct data point in the license-tightening playbook, sitting alongside the fork outcomes of Vault/OpenBao, Terraform/OpenTofu, and Elasticsearch/OpenSearch, and the closure outcome of CockroachDB. Together they map the full range of what happens when a vendor decides the open license that made it popular is no longer the license it wants.
28. The Irony of the SSPL
There is a deep irony in the SSPL's outcome. It was written to force cloud providers to pay or stop, and instead it pushed the largest of them to build compatible engines that capture the same customers without licensing MongoDB. It was written to protect MongoDB's commercial upside, and instead it fragmented the ecosystem and handed an opening to an Apache-2.0 alternative. None of this killed MongoDB — Atlas is thriving — but it demonstrated that in open-source infrastructure, a license change is a double-edged weapon that can cut the vendor as surely as the competitor. The SSPL is now the cautionary tale that every later relicensing cites, sometimes to justify a different approach.
29. Honest Limitations
Let me state the weaknesses plainly. FerretDB is not 100% MongoDB-compatible; change streams, certain auth methods, and some aggregation stages have gaps. It carries a translation performance tax at extreme throughput. It is younger and smaller than MongoDB's ecosystem. And it depends on Postgres — which is a strength for Postgres shops and a requirement for everyone else. MongoDB Community Server, meanwhile, carries the SSPL's compliance friction and the risk that your distribution or tooling will not support it. Neither option is perfect; the choice is between a non-OSI license on the original and a compatible reimplementation on open foundations. For a sovereignty-minded operator, the reimplementation is the principled pick.
30. The DocumentDB Extension Deep Dive
The engine that resurrected self-hosted MongoDB compatibility deserves its own look. Microsoft's DocumentDB PostgreSQL extension, open-sourced under MIT in early 2025, adds a native BSON type and document-oriented operators directly inside PostgreSQL. Rather than marshaling JSON into text and parsing it back on every operation, the extension stores BSON as a first-class column type, letting FerretDB translate Mongo queries into Postgres operations that execute against native document structures. This is the source of the claimed 20x performance improvement over FerretDB 1.x, which lacked it. The strategic irony is delicious: Microsoft, a cloud provider that built its own MongoDB-compatible service, open-sourced the engine that lets the open community run MongoDB workloads on Postgres better than before. The extension is the bridge that turned FerretDB from a clever workaround into a credible primary database, and its MIT license means it can be embedded, modified, and redistributed freely — the exact openness the SSPL withdrew.
31. FerretDB in Production: A Year of Lessons
A year after FerretDB 2.0's GA, the operational lessons are clear. Teams that succeed treat it as Postgres first and Mongo second: they size and tune the underlying Postgres, configure replication and backups as they would for any Postgres deployment, and validate their actual aggregation pipelines against the compatibility matrix before cutover. Teams that struggle are those that assumed a literal drop-in and hit an unsupported feature — usually change streams or an exotic aggregation stage — late in a migration. The cost profile is favorable: no FerretDB license fee, and Postgres is infrastructure most teams already run. The maturity signal is that FerretDB Cloud now exists for teams that want managed Postgres-durability without running it, which is the same managed-escape-hatch pattern the rest of this license wave produced. The verdict a year in: FerretDB is no longer a stopgap; for common MongoDB workloads it is a finished, license-clean home.
32. The Future: Will MongoDB Reopen?
A fair question is whether MongoDB might ever return to an OSI-approved license, reversing the 2018 decision. The honest answer is that there is no signal it will. MongoDB Inc. has built a successful business on Atlas and the SSPL's protective perimeter, and reversing course would undo the very competitive moat the SSPL was designed to create. The SSPL has, from the company's perspective, worked: it pushed cloud providers to compatible reimplementations rather than unlicensed MongoDB, and Atlas continues to grow. The open community's realistic future is not "MongoDB reopens" but "FerretDB and Postgres absorb the sovereignty-sensitive demand." That framing matters for planning: do not build a roadmap that assumes the license will improve; build one that assumes the SSPL is permanent and choose your stack accordingly. The prudent operator plans for the license that exists, not the one they wish existed.
33. The Hidden Bonus: Your Documents Live in Postgres
A genuine, often-overlooked advantage of FerretDB is that your "MongoDB" data is actually in PostgreSQL, which means you can query it with SQL. Because the documents are stored as native BSON columns, you can write a
SELECT that joins your document collection against a relational table, run analytical queries with the full power of Postgres, or use any Postgres tool — BI connectors, replication, FDWs — against data your application thinks is MongoDB. Teams that adopt FerretDB often discover they have accidentally unified their document and relational worlds: the application enjoys Mongo ergonomics, while analysts and downstream systems enjoy Postgres. This is a benefit no SSPL MongoDB deployment gives you, because MongoDB's storage is its own opaque format. The reimplementation that the SSPL forced turns out to open a door MongoDB's architecture kept closed — another instance of the license change producing an outcome the vendor did not intend.
34. The Driver Ecosystem Is the Real Moat
It is worth naming what actually keeps MongoDB central: not the server license, but the driver ecosystem. MongoDB's official drivers for Python, Node, Go, Java, Rust, and a dozen other languages are mature, well-documented, and battle-tested, and they are Apache-2.0-licensed and freely reusable regardless of the server's SSPL. FerretDB's great fortune is that it reuses these exact drivers unchanged — your application code never knows the server swapped. This is the quiet lesson of the SSPL saga: the client-side ecosystem, being permissively licensed, survived the server's tightening intact, and it is the client that makes the protocol-rebuild path viable. MongoDB Inc. can change the server license, but it cannot unpublish the drivers' openness, and that openness is what lets the community route around the SSPL. The moat, it turns out, was always on the client side.
35. Bottom Line
MongoDB did not die in 2018; it became the cautionary tale. By replacing the AGPL with the SSPL, it launched the modern license controversy, got dropped by Linux distributions, was bypassed by cloud providers building compatible engines, and inspired FerretDB — an Apache-2.0 layer that speaks Mongo on PostgreSQL and removes the legal migraine entirely. For new work that does not need MongoDB's newest or enterprise features, FerretDB is the license-clean choice and a near-drop-in for common workloads. For teams deep in MongoDB's advanced features or committed to Atlas, the SSPL may be a non-issue. The takeaway is that the SSPL did not remove your options; it multiplied them — just not in the way MongoDB Inc. intended. Verify the license of whatever you deploy against the LICENSE file, prefer FerretDB if sovereignty and compliance matter to you, and you have made the architectural choice this entire article argues for.
Related:
Comments (0)
No comments yet. Be the first to comment!