Amazon DocumentDB
Amazon DocumentDB is a managed document database that implements the MongoDB API. It stores JSON documents with flexible schemas, and it is the AWS-native destination for MongoDB workloads that a team no longer wants to operate itself.
It is not MongoDB. It emulates the MongoDB wire protocol and API on top of AWS’s own distributed storage engine — the same architectural idea as Aurora — which is why its scaling and availability behaviour resembles Aurora more than it resembles a MongoDB replica set. Compatibility is good but not total, so the specific MongoDB version and feature set an application depends on is the thing to check before committing.
Documents
Section titled “Documents”Data is stored as JSON documents. Fields can be added or removed per document without a migration, nested structures are stored and retrieved whole, and a document is returned as a single unit rather than reassembled from joined rows.
The advantage is that the storage shape matches the shape the application already works with, which shortens the distance between the code and the database and makes iteration fast. The corresponding cost is that consistency of structure is the application’s responsibility, not the database’s.
Architecture
Section titled “Architecture”Storage is separated from compute and replicated across Availability Zones, so cluster capacity and cluster durability scale independently.
- One primary instance plus up to 15 read replicas.
- The primary handles all writes; the primary and every replica serve reads.
- Storage grows automatically as data is added.
- Failover to a replica is automatic if the primary fails.
- Both write-then-read consistency and eventual consistency are available, depending on which endpoint a read goes to.
Endpoints
Section titled “Endpoints”- Cluster endpoint — always resolves to the current primary; use it for writes.
- Reader endpoint — load-balances reads across the replicas.
- Instance endpoints — address one instance directly.
Unlike Aurora, DocumentDB has no custom endpoints: routing to a named subset of instances is not something the service does.
Where it fits
Section titled “Where it fits”User profiles. One document holds everything about a user, including optional and per-user fields, without a sparse table or an entity-attribute-value schema.
Content management. Articles, listings and product records vary in structure by type; a document store accommodates that without a schema change per content type.
Real-time applications over document data. Event and telemetry payloads that arrive as JSON can be stored as they arrive rather than flattened first.
Migrating from MongoDB
Section titled “Migrating from MongoDB”Two things make the move practical.
API compatibility. Existing MongoDB drivers and, for the most part, existing queries work unchanged, so an application usually needs a connection string change rather than a rewrite. Validate against the MongoDB version and feature set DocumentDB implements before assuming this — unsupported operators and commands are the usual source of surprises, and are best discovered by running the application’s test suite against a DocumentDB cluster.
AWS Database Migration Service. DMS supports MongoDB as a source and DocumentDB as a target, and can run continuous change data capture so that the cutover happens after the target has caught up rather than during a long outage.
The decision is essentially operational: DocumentDB trades some MongoDB fidelity, and the option of running anywhere, for AWS running the cluster. If the fidelity matters more than the operations do, MongoDB Atlas or self-managed MongoDB on EC2 remain the alternatives.