DocumentDB 1.0 Reaches General Availability With MIT License and MongoDB Protocol

The open source DocumentDB project has reached version 1.0, its first general availability (GA) release, according to a report by InfoQ published on November 14, 2026. It is a document database licensed under MIT, built as a PostgreSQL extension, capable of responding to the MongoDB wire protocol. In practice, most MongoDB drivers, tools, and queries work without modification.

For those who already run PostgreSQL in production and have long coveted MongoDB's API (or the other way around), the proposal is straightforward: swap the backend without rewriting the data access layer. That changes the calculus for anyone currently paying for a MongoDB Enterprise license, using managed Atlas for lack of a free alternative, or avoiding migration because rewriting queries would be too costly.

How Compatibility Works Under the Hood

DocumentDB is not a database rewritten from scratch: it is a PostgreSQL extension combined with a gateway. The extension implements MongoDB API-compatible functionality inside PostgreSQL itself, and the gateway translates MongoDB protocol requests into PostgreSQL calls. The result is Postgres underneath, speaking Mongo on the front end.

Version 1.0 supports PostgreSQL 15 through 18 via container images, with native Linux packages available for versions 17 and 18. It also includes a Kubernetes operator for those who already orchestrate databases in clusters. The GA's declared focus was security, stability, and fixes in indexing, aggregation, and geospatial queries, areas that are typically troublesome in any compatibility layer.

Where the Project Came From

Microsoft announced the open source project in early 2025, aiming to give the community a NoSQL datastore built on PostgreSQL with full visibility into the engine's architecture and implementation. Months later, the project joined the Linux Foundation, gaining support from other database organizations such as AWS, Cockroach Labs, Google, Snowflake, and Yugabyte.

That governance detail matters more than it seems. A project hosted by a single company can change its license overnight (which is exactly what MongoDB did when it moved to the SSPL). With multiple competing companies maintaining the same code under the Linux Foundation, the chance of a unilateral license change drops considerably.

Why MIT and Not SSPL

The license is the centerpiece of the proposal. In an article of its own, titled "DocumentDB and the MIT License: What to Know Before You Build, Deploy, and Distribute," the team explains that the permissive MIT license allows commercial use, modification, and hosting of the database without requiring disclosure of proprietary code running on top of it.

This contrasts directly with MongoDB's SSPL, which requires anyone offering the database as a managed service to open-source their own management layer code. It was this clause, remember, that led Amazon to keep AWS's DocumentDB as a closed product and inspired forks such as Percona Server for MongoDB. For anyone considering offering managed hosting of the database to customers, the license difference is the project's whole reason for existing.

The Name That Confuses Everyone

There's a problem the community didn't let slide: the name. AWS has sold, for years, a service called Amazon DocumentDB, MongoDB-compatible but entirely unrelated to this project. The open source DocumentDB team even published a disambiguation page covering the open source project, Azure DocumentDB, and Azure Cosmos DB, but the confusion persists.

In a popular Hacker News thread, user marifjeren summed up the frustration:

Name it anything else for god's sake. DocumentDB is already what everybody calls Amazon DocumentDB.

marifjeren, Hacker News user

A practical warning is in order: when searching for "DocumentDB" to decide between options, it's easy to land on the wrong documentation and mix up concepts from completely different products.

Not the Only Game in Town: The Comparison With FerretDB

DocumentDB 1.0 isn't competing alone for the audience that wants MongoDB without SSPL. FerretDB is a separate project that uses DocumentDB's extensions as a backend and implements its own MongoDB-compatible interface on top. Patty Chow, Microsoft's product manager on the project, explained why it makes sense to have multiple implementations coexisting:

MongoDB has given developers a widely used way to work with document data. Familiar drivers and query patterns are worth preserving. Alternative implementations give developers a chance to keep using that knowledge while evaluating different approaches to storage and deployment.

Patty Chow, product manager at Microsoft

In a Reddit thread, those who have tested both products raise concerns. User 716green commented:

Compatibility between MongoDB and FerretDB has been absolutely minimal compared to what you would probably expect. I've been a fan of DocumentDB for a long time and I love that Microsoft is supporting FerretDB.

716green, Reddit user

What the Preliminary Numbers Say

Layerbase ran an initial comparison between FerretDB and PostgreSQL-based DocumentDB using YCSB benchmarks. The result: DocumentDB delivered 20% to 33% higher read throughput, while FerretDB showed lower tail latency on updates under mixed workloads. Layerbase itself classified the results as inconclusive.

In the opposite direction, an issue opened on the project's GitHub reports higher query latency in DocumentDB 1.0 than in MongoDB 9.0.4, across several tested workloads. This result also hasn't been independently verified. Putting both ends together: anyone evaluating the project for production still needs to run their own benchmark on their own workload before trusting any number published so far.

What Remains Open

The project's release notes include upgrade paths and a list of known issues. The team has already signaled plans for separate long-term support (LTS) and development tracks, but the versioning policy is still under discussion, with no set date to be finalized.

For anyone evaluating adoption now, the message is: the technical foundation (PostgreSQL extension + gateway, MIT license, multi-company governance via the Linux Foundation) is solid enough for a 1.0. What still needs to mature is exactly what tends to hurt in real migrations: fine-grained compatibility parity in edge cases, performance under production load, and a versioning policy that gives predictability to those putting this into production.