DocumentDB vs MongoDB: what 1.0 does and does not give you

DocumentDB vs MongoDB is not a like-for-like choice yet. DocumentDB 1.0 is an MIT-licensed layer that speaks the MongoDB wire protocol on top of PostgreSQL, and its own release post calls it a stabilization release. Pilot it against a copy of your workload. Don't migrate production because of the licence alone.

The timing is easy to misread. InfoQ's headline on 14 November 2026 says DocumentDB 1.0 reaches general availability, but the project's post is dated 19 October 2026. In the four weeks between, a latency bug report was opened the day after release, and the release notes carry a list of known issues. Both matter if you are deciding now (as of 15 November 2026).

DocumentDB vs MongoDB: what 1.0 actually is

Microsoft released DocumentDB in January 2025 as an MIT-licensed engine built on PostgreSQL, the one it says powers the vCore-based Azure Cosmos DB. On 25 August 2025 the Linux Foundation announced the project's move with AWS, Cockroach Labs, Google, Microsoft, Rippling, SingleStore, Snowflake, Supabase, Ubicloud and Yugabyte named as industry participants.

Mechanically it is two parts: PostgreSQL extensions that store native BSON, and a gateway that speaks the MongoDB wire protocol. The release post says most MongoDB drivers, tools and queries work against it unchanged, without naming a MongoDB API version. Container images cover PostgreSQL 15 to 18; Linux packages cover PostgreSQL 17 and 18 on Ubuntu 24.04 and EL9.

Question	MongoDB	DocumentDB 1.0
Licence	SSPL, with a service clause in section 13	MIT
Engine	MongoDB's own server	PostgreSQL extensions plus a wire-protocol gateway
Drivers and tools	Native	"Most" work unchanged, per the release post

The licence row is the reason most people look. The project's own licence post notes that the SSPL is not OSI-approved, and section 13 of the licence text requires source disclosure if you make the program's functionality available to third parties as a service. We come back to when that actually applies below.

Three services are called DocumentDB, and they are not one product

Search results for this topic mix up three services. Getting them straight is the first piece of due diligence, because a benchmark, a price or a compatibility claim about one says nothing about the others.

• DocumentDB (the open-source project). The MIT-licensed Linux Foundation project, whose copyright line reads "DocumentDB a Series of LF Projects, LLC".
• Azure DocumentDB (with MongoDB compatibility). Microsoft's managed service. Microsoft's documentation says it was previously named vCore-based Azure Cosmos DB for MongoDB and is built on the open-source engine. Azure Cosmos DB for MongoDB (RU) is a different service on a different engine, according to the project's disambiguation post.
• Amazon DocumentDB. A separate AWS service. AWS describes it as a fully managed database with MongoDB compatibility. AWS is a named participant in the Linux Foundation project, but Amazon's service is not the project.

The 1.0 release notes list known issues that touch data correctness

A published list is better than a silent one. Read it for what kind of problem each item is, though, because the first three below are not missing features. They are cases where the database can do the wrong thing. These are from the 1.0 release notes:

• Double-applied writes. If the backend connection drops after a commit but before the reply, the gateway retries, and non-idempotent updates such as $inc can apply twice, even with retryWrites=false.
• Missed single-document match. Updates with multi: false, or findAndModify filtering on fields other than _id, can miss a match under a generic plan. With upsert that can insert a duplicate. The notes call it rare with default settings and give a plan_cache_mode workaround.
• Backend crash on grouped views. distinct or count on a view whose pipeline ends in $group can crash the PostgreSQL backend, which restarts and disconnects every other session.
• $lookup with a wildcard index fails with "Unrecognized BSON data type code 0".
• Collation is off by default, and distinct, findAndModify and update don't support it at all.
• Uncancellable expensive operations. Costly $replaceAll or $regexFindAll calls can run past maxTimeMS.

The same notes show 1.0 tightening $merge and $out to require insert or update permission on the target rather than read alone. Upgrades have sharp edges too: a 1.0 container image on an existing volume does not update the extensions, so the documented route is a new volume with mongodump and mongorestore, and release candidates have no upgrade path.

One benchmark skips MongoDB and one bug report doesn't

The benchmark most often cited is Layerbase's October 2026 YCSB comparison, and it compares DocumentDB with FerretDB, not with MongoDB. On 10 million records on a 4-vCPU, 8 GB machine, the read-only workload gave FerretDB 4,265, 4,342 and 4,100 ops/sec at 16, 64 and 256 threads against DocumentDB's 5,122, 5,338 and 5,462. On the 50/50 mix at 256 threads, p99 update latency was 2,226.2 ms for DocumentDB and 931.3 ms for FerretDB.

Read the caveats before you quote any of that. Layerbase sells hosting for both FerretDB and DocumentDB, ran one pass per stack with no confidence intervals, and did not test aggregations, transactions, change streams or failover. Its own conclusion is that neither result alone justifies migrating a production application. We made a similar point in reading the benchmark before you leave pgvector: the methodology paragraph is the finding.

The MongoDB comparison is GitHub issue 806, opened on 20 October 2026. The reporter ran DocumentDB 1.0.0 against MongoDB 9.0.4 on identical data and 4 CPU, 4 GB limits and found simple indexed reads within 1.1x to 1.2x. They report 1.5x to 6x slower on paginated $facet, deep $skip, $lookup, $group and updateMany; a whole-collection $group took 115.39 ms against 18.69 ms. A maintainer replied on 3 November that they were looking at the scenarios, and pointed to a commit for the anchored-regex case. We haven't reproduced any of these numbers, and the dataset is synthetic and untuned. Treat the issue as a list of what to test, not a verdict.

The strongest case for moving, and where it stops

The case for DocumentDB is stronger than "it's free". It has three parts.

First, licence exposure. On its face the SSPL text permits running the unmodified program, and the section 13 trigger is offering its functionality to third parties as a service. A company using MongoDB behind its own application is probably outside that. A company whose product exposes database access or query functionality to customers may not be, and that is a question for counsel, not for this post. MIT removes the question.

Second, governance. A project hosted by the Linux Foundation with AWS, Google and Microsoft all named participants is a different kind of dependency from a single-vendor one.

Third, there is a managed route. Microsoft says Azure DocumentDB runs the same engine, supports 99.03% of MongoDB operators and costs 40% less on average than MongoDB Atlas on AWS. Those are vendor claims about a managed service, not about the open-source engine, and Microsoft itself says savings depend on configuration. Choosing between running the engine yourself and buying it managed is a cloud consulting decision as much as a database one.

The case against is just as concrete. The release page names no production adopters. The long-term-support policy is still open: the release post points to an RFC on versioning and releases, which was opened in April 2026 and was not merged when we checked. And the known issues include writes that can apply twice. For a system of record, that last item outweighs a licence argument.

A pilot plan: six things to test before you commit

The pilot is where this decision gets made. We work with both MongoDB and PostgreSQL but have not run DocumentDB, so this is our suggested order, built from the public issues above, not from a deployment.

1. Replay your real pipelines. Run your actual aggregations, especially anything with $facet, $lookup, $group, deep $skip or updateMany, on a copy at production volume. Compare p95 against your own MongoDB numbers, not against anyone's blog.
2. Audit non-idempotent writes. List every $inc and upsert. Ask what a doubled write costs, and make the important ones idempotent with an operation key before the pilot.
3. Test update filters off _id. Exercise multi: false updates and findAndModify on other fields, with and without the documented plan_cache_mode setting.
4. Check collation and geospatial. Collation is off by default and unsupported in three commands; the notes also list ordering fixes for $near and $geoNear on 2dsphere indexes.
5. Rehearse operations. PostgreSQL upgrades, backups, the volume-migration route for containers, and user management: the notes list an admin authorization failure on createUser with a package-install workaround. Rehearse the data move, not only the queries; our piece on why go-live fails on data, not software covers the same pattern in ERP.
6. Write exit criteria first. For example: no lost or doubled writes across a full replay, and p95 within a margin you set in advance. Decide before you see the results.

Stay on MongoDB if your product leans on aggregation-heavy reads, if you can't tolerate any duplicate-write risk, if you need documented support windows, or if your only motive is licence worry while MongoDB sits purely behind your own application.

Scope the pilot before you scope the migration

If you are weighing a move off MongoDB, our custom software development team can build the replay harness and the pilot plan around your own workload, and tell you plainly if staying put is the better answer. We have no DocumentDB production evidence to offer, which is why the pilot comes first.