DocumentDB vs MongoDB: Amazon, Azure, and Open-Source DocumentDB Compared

DocumentDB vs MongoDB used to be a simple question about one AWS service. It is now a question about three products that share a name. Amazon DocumentDB is AWS's managed database with a MongoDB-compatible API. DocumentDB, with no prefix, is an open-source, MIT-licensed engine built on PostgreSQL and governed by the Linux Foundation. Azure DocumentDB is Microsoft's managed service built on that open-source engine.

None of them runs MongoDB's code. All three accept MongoDB drivers and implement a large part of the MongoDB API, and all three have gaps you need to test for.

The short verdict: use MongoDB (self-hosted or Atlas) when you want the full feature set and the latest releases. Use Amazon DocumentDB when AWS integration matters more than feature parity. Use the open-source DocumentDB engine, directly or through FerretDB, when you want a permissive licence and PostgreSQL underneath. Use Azure DocumentDB when you want that same engine as a managed Azure service.

Which DocumentDB do you mean?

The name has a messy history, so it is worth pinning down before comparing anything.

• Amazon DocumentDB (with MongoDB compatibility) launched in 2019. AWS describes it as an engine that "emulates" the MongoDB APIs on "a purpose-built database engine that utilizes a distributed, fault-tolerant, self-healing storage system."
• DocumentDB (open source) started at Microsoft in 2024 as PostgreSQL extensions that add a BSON type and document operations. It joined the Linux Foundation in August 2025 under the MIT licence. AWS joined the project too, and stated that Amazon DocumentDB "is a different engine" from it.
• Azure DocumentDB is the new name, since November 18, 2025, for what was Azure Cosmos DB for MongoDB (vCore). It runs the open-source DocumentDB engine.
• Azure DocumentDB (2014 to 2017) was an older Microsoft service that became Azure Cosmos DB. It has nothing to do with the current products beyond the name.

The rest of this post compares MongoDB with Amazon DocumentDB first, since that is what most people searching "DocumentDB vs MongoDB" are weighing, then with the open-source engine and its Azure service.

Amazon DocumentDB vs MongoDB: architecture

A MongoDB replica set is a group of servers that each hold a full copy of the data. The primary takes writes, and secondaries replay the primary's oplog. To scale writes, you shard across several replica sets.

Amazon DocumentDB separates compute from storage. A cluster has one primary instance and up to 15 replica instances, and they all share one cluster storage volume. That volume keeps six copies of your data across three Availability Zones and grows automatically in 10 GB increments, up to 256 TiB on engine version 8.0. Replicas do not replay writes. They read the same storage, which AWS says keeps replica lag "often down to single digit milliseconds."

This design has practical effects:

• Adding a read replica is fast, because there is no data to copy.
• Failover promotes an existing replica, and the database cache survives instance restarts.
• Write scaling on an instance-based cluster stops at one primary. For more, AWS offers elastic clusters, which shard across multiple nodes.
• Serverless capacity is available in DocumentDB Capacity Units (DCUs), which scale compute up and down with demand.

Compatibility: what is different

Amazon DocumentDB supports MongoDB 4.0, 5.0, and 8.0 API compatibility. Most drivers, mongosh, and common CRUD and aggregation code work unchanged. The differences show up at the edges, and AWS lists them in its functional differences guide. The ones most likely to bite:

• No admin or local database, and no system.* collections. mongodump and mongorestore skip the admin database, so you recreate users and roles yourself. AWS recommends MongoDB Database Tools up to version 100.11.0.
• Retryable writes are only supported from engine version 8.0.2. Older clusters return Retryable writes are not supported unless you connect with retryWrites=false, and most drivers enable retryable writes by default.
• One index build per collection at a time. A second createIndex() or dropIndex() on the same collection fails while a build is running.
• explain() output differs, because the query planner is different. You may need hint() where MongoDB would pick the right index on its own.
• Result order is not implicit. Without sort(), you can get rows back in a different order than MongoDB returns them.
• Reverse $natural scans ({ $natural: -1 }) are not supported.

Amazon DocumentDB 8.0 closed many older gaps. It added views, collation, $merge, $bucket, $set, $unset, a new text index version, and correlated $lookup subqueries from 8.0.2. If you evaluated Amazon DocumentDB years ago and walked away, the picture is better now. It is still not MongoDB.

Transactions

Both support multi-document ACID transactions across collections. MongoDB has had them since 4.0 for replica sets and 4.2 for sharded clusters. Amazon DocumentDB supports them from its 4.0 engine.

The limits differ. In Amazon DocumentDB, transactions have a one-minute execution limit, the transaction log must stay under 32 MB, and read concern is always snapshot. A local or majority read concern is upgraded to snapshot, and linearizable returns an error. AWS also points out that single statements that modify many documents, such as updateMany, are atomic for each document but not across the full operation, so wrap them in a transaction if you need all-or-nothing.

MongoDB's default transaction lifetime is 60 seconds, and 9.0 adds a default limit of 10,000 concurrently open multi-document transactions.

The open-source DocumentDB engine vs MongoDB

The open-source DocumentDB project has three parts: pg_documentdb_core adds the BSON type to PostgreSQL, pg_documentdb provides the document API, and a gateway translates the MongoDB wire protocol into calls on those extensions. FerretDB 2.0 uses the same extension as its engine.

I ran the project's documentdb-local Docker image alongside MongoDB 8.3 and connected to both with the same mongosh. DocumentDB introduces itself as MongoDB 7.0, with the real engine version underneath:

db.version()
db.adminCommand({ hello: 1 }).internal

7.0.0
{ documentdb_versions: [ '0.117-0', '0.117.0' ], kind: '' }

Inside the container is PostgreSQL 17 with the documentdb, documentdb_core, vector, and postgis extensions. Collections are PostgreSQL tables, and you can read them from SQL:

SELECT document FROM documentdb_api.collection('shop', 'orders');

                                                     document
-------------------------------------------------------------------------------------------------------------------
 { "_id" : { "$numberInt" : "4" }, "customer" : "grace", "status" : "pending", "total" : { "$numberInt" : "36" } }
 { "_id" : { "$numberInt" : "5" }, "sku" : "MS-02", "status" : "pending" }
(2 rows)

Then I ran one test script against both servers. MongoDB 8.3 accepted every operation. DocumentDB rejected five:

capped: ERROR CommandNotSupported Capped collections not supported yet
timeseries: ERROR CommandNotSupported Time series data collections are currently not supported
textIndex: OK
where: ERROR BadValue unknown top level operator: $where. If you have a field name that starts with a '$' symbol, consider using $getField or $setField.
mapReduce: ERROR CommandNotSupported Command 'mapReduce' not supported.
lookupPipeline: OK
graphLookup: OK
changeStream: ERROR CommandNotSupported Stage $changeStream is not supported yet in native pipeline
collMod: OK

The results that matter for most applications passed. A transaction that inserted an order and decremented stock in a second collection committed on both servers, and a $lookup with let and a sub-pipeline returned identical output. The failures are features many apps never touch, but if yours uses change streams or time series collections, this build is not ready for it. mapReduce has been deprecated in MongoDB since 5.0, so its absence mostly affects old code.

DB Pro

Work With Your Databases Like A Pro

Query, explore, and manage your databases with a beautiful desktop app and built-in AI.

Download Now

Azure DocumentDB

Azure DocumentDB is the managed version of the open-source engine. It uses dedicated vCore cluster tiers billed for compute and storage, supports vertical and horizontal scaling, includes vector search, and offers a free tier. Microsoft markets it as "99.03% MongoDB-compatible", a figure that comes from Microsoft rather than an independent test.

The managed service can differ from the open-source build you run locally, so check Microsoft's compatibility pages for the features that failed above. Azure also still sells the RU-based Azure Cosmos DB for MongoDB, which is a different engine again. Our Cosmos DB vs MongoDB comparison covers that split.

Pricing models

Prices change often, so compare models rather than numbers.

• MongoDB Atlas bills dedicated clusters per tier per hour. Small workloads can use the Flex tier, which has a base fee plus usage and a monthly cap. Self-hosted Community Server has no licence fee.
• Amazon DocumentDB bills instance hours, storage, I/O requests, and backup storage on standard clusters. The I/O-optimized storage configuration removes per-I/O charges in exchange for higher instance and storage rates. AWS suggests it when I/O would exceed 25% of your cluster spend. Serverless bills DCUs.
• Open-source DocumentDB costs whatever the PostgreSQL servers you run it on cost.
• Azure DocumentDB bills cluster compute tier and storage.

For Amazon DocumentDB, I/O charges are the line item that surprises people. Model your read and write volume before choosing standard storage.

Migrating between MongoDB and a DocumentDB

All three DocumentDB products accept mongodump/mongorestore and mongoexport/mongoimport. AWS also supports AWS Database Migration Service for moving data from MongoDB into Amazon DocumentDB.

Before migrating, run your application's integration tests against the target, with the connection options it will use in production. Look for CommandNotSupported errors, differences in sort order where you forgot a sort(), and slower queries caused by different index selection. A GUI client like DB Pro's MongoDB desktop client helps with spot checks while you compare collections.

When to choose MongoDB

• You need the newest features on release day, such as MongoDB 9.0's changes or self-managed Search and Vector Search.
• You rely on change streams, time series collections, or other features the compatible engines lack or limit.
• You want the same database on every cloud and on-premises.
• You want MongoDB's own support and tooling.

When to choose Amazon DocumentDB

• Your platform is on AWS and you want IAM, VPC, CloudWatch, and AWS billing.
• The workload is read-heavy and benefits from fast replicas on shared storage.
• Your app uses mainstream CRUD, indexes, and aggregation, and passes your tests on it.

When to choose open-source DocumentDB or Azure DocumentDB

• You want an MIT-licensed engine you can self-host, or FerretDB's Apache 2.0 packaging of it.
• Your team already runs PostgreSQL and wants document storage on the same platform.
• You are on Azure and moving an existing MongoDB application there.

Verdict: DocumentDB vs MongoDB

MongoDB is the reference implementation, and every DocumentDB is measured against it. If you need complete compatibility, run MongoDB or Atlas.

If your reason for looking is cloud alignment or licensing, a DocumentDB can be the right choice, as long as your application passes a compatibility test first. Amazon DocumentDB suits AWS shops. The open-source engine and Azure DocumentDB suit teams who want a permissive licence and PostgreSQL underneath. For the wider field, see our MongoDB alternatives guide and the DynamoDB vs MongoDB comparison.