Amazon DocumentDB
Fully managed, MongoDB API-compatible document database for JSON data.
Verified against AWS documentation · 2026-09-09
Key facts
- 01MongoDB API-compatible — existing MongoDB apps, drivers, and tools connect with no code changes
- 02Cluster = one write primary + up to 15 read replicas sharing one storage volume; failover to a replica is automatic
- 03Storage auto-grows in 10 GiB steps to 4 PiB, replicated 6 ways across 3 AZs — you're billed for one copy
- 04Two capacity modes: Serverless scales automatically for spiky traffic, provisioned instances for steady, predictable load
Exam triggers
Phrases and scenarios that point here.
- "MongoDB", "JSON documents", "flexible schema", "records with varying attributes" → DocumentDB
- "Move our self-managed MongoDB to AWS without rewriting the app" → DocumentDB, migrated with DMS
- Read traffic is swamping the primary → add read replicas (up to 15), don't just resize the instance
- "NoSQL at any scale" with no mention of MongoDB → DynamoDB, not DocumentDB
Not this service
- Serverless key-value at any scale with no MongoDB API requirement → DynamoDB
- Managed Apache Cassandra workload → Amazon Keyspaces
- Relationships and graph traversal (fraud rings, social graphs) → Amazon Neptune
Use cases
- 01Product catalogs where every category carries different attributes — a bike frame has geometry numbers, a jersey has sizes — and adding a field doesn't mean a schema migration
- 02Player and user profiles that keep growing: achievements, inventory, and settings all live in one document fetched in a single read
- 03Lifting a self-managed MongoDB replica set off EC2 or on-prem when the team wants the same queries and drivers but no more patching, sharding, or backup scripts
- 04Content and CMS backends — an article with its nested comments, tags, and metadata stored as one document instead of six joined tables
- 05Vector search for RAG applications, keeping embeddings beside the source documents so one database serves both retrieval and app data
How it's charged
- 01Instance-based clusters bill on four dimensions: instance hours, I/O per million requests, storage per GB-month, and backup storage — no upfront commitment
- 02Standard vs I/O-Optimized storage config is the big cost lever: if I/O exceeds ~25% of cluster spend, I/O-Optimized drops the separate I/O charge for a higher flat rate
- 03Serverless bills DocumentDB Capacity Units (DCUs) per second from a 0.5 DCU floor — it scales down but never to zero, so an idle Serverless cluster still costs money
- 04Storage is replicated six ways across three AZs but charged once; backup storage up to 100% of your cluster storage is free, as is cross-AZ replication traffic
- 05Instances can be stopped for up to 7 days to pause compute (storage keeps billing); new accounts get a 30-day trial covering 750 hours of db.t3.medium, 5 GB storage, and 30 million I/Os
