DynamoDB vs Amazon DocumentDB

Both are fully managed AWS NoSQL databases, but they solve different problems.
DynamoDB is a serverless key-value and document store; Amazon DocumentDB is a
MongoDB-compatible document database. This page compares them factually so you
can pick the right one before you commit to a data model.

What is the difference between DynamoDB and DocumentDB?

DynamoDB is a serverless key-value and document database with no servers or
clusters to manage — you scale by request volume or provisioned capacity.
Amazon DocumentDB is a MongoDB-compatible document database that runs on a
cluster of instances (a primary plus read replicas). DynamoDB uses its own API;
DocumentDB speaks the MongoDB API, so existing MongoDB apps, drivers, and tools
work against it.

DynamoDB vs Amazon DocumentDB at a glance

Characteristic	DynamoDB	Amazon DocumentDB
Data model	Key-value and document (items with typed attributes)	Document (JSON/BSON documents in collections)
Query API	DynamoDB API (GetItem, Query, Scan, PutItem, UpdateItem) plus PartiQL	MongoDB API — the same drivers, tools, and mongo/mongosh shell you use with MongoDB
Max record size	400 KB per item	16 MB per document (BSON, the MongoDB document limit)
Indexes	Global secondary indexes (GSI) and local secondary indexes (LSI)	MongoDB-style secondary indexes, including compound indexes
Consistency	Eventually consistent by default; optional strongly consistent reads; ACID transactions	Reads from the primary are strongly consistent; replica reads can be eventually consistent (read preference); ACID transactions
Scaling / provisioning	Serverless — no instances or clusters; on-demand or provisioned capacity	Instance-based cluster (a primary plus up to 15 replicas) or elastic clusters; a serverless instance class is also available
Pricing model	Pay-per-request (on-demand) or provisioned read/write capacity, plus storage	Per-instance-hour compute, plus I/O requests, storage, and backup storage
Best fit	High-scale key-value and serverless workloads with known access patterns	Existing MongoDB workloads and document apps that need the MongoDB API on AWS

Sizes follow each service's own documentation. DynamoDB measures size in
binary units (1 KB = 1024 bytes); the 16 MB DocumentDB figure is the standard
MongoDB BSON document limit.

When DynamoDB is the better choice

• You want zero infrastructure to manage. DynamoDB has no instances, clusters, or replicas to size, patch, or fail over — you create a table and read/write it. Capacity is either on-demand (pay per request) or provisioned.
• Your workload is key-value or single-table with known access patterns. DynamoDB rewards designing around your queries up front. See how to model data in DynamoDB and single-table design.
• You need predictable performance at very high scale. DynamoDB delivers single-digit-millisecond reads and writes that stay flat as traffic grows.
• You're building serverless on AWS. DynamoDB pairs naturally with Lambda and pay-per-request billing, with no idle instance cost.

When DocumentDB is the better choice

• You already run MongoDB. DocumentDB is MongoDB-API-compatible, so your existing drivers, tools, and application code can often connect with minimal changes — useful for a lift-and-shift onto AWS.
• You need large documents or rich, ad-hoc queries. DocumentDB's 16 MB document limit is far larger than DynamoDB's 400 KB item, and the MongoDB query language supports flexible filtering and aggregation without pre-designing every access pattern.
• You prefer a document-first model with a familiar API. If your team thinks in MongoDB collections and documents rather than partition/sort keys, DocumentDB keeps that mental model.

Neither is strictly "better" — DynamoDB trades query flexibility for hands-off
serverless scale, while DocumentDB trades serverless simplicity for MongoDB
compatibility and larger, more flexible documents.

What a DocumentDB cluster becomes in DynamoDB

Because DocumentDB speaks the MongoDB API, the query rewrite here is the MongoDB
rewrite, and the DynamoDB vs MongoDB page covers it. The part
that is specific to DocumentDB is everything around the query. It starts before you
write one:

aws docdb create-db-cluster \
  --db-cluster-identifier orders --engine docdb \
  --master-username admin --master-user-password "$PW"

aws docdb create-db-instance \
  --db-instance-identifier orders-1 --db-cluster-identifier orders \
  --engine docdb --db-instance-class db.r6g.large

aws docdb create-db-instance \
  --db-instance-identifier orders-2 --db-cluster-identifier orders \
  --engine docdb --db-instance-class db.r6g.large

Two instances, because AWS is explicit that "for failover to function, your cluster
must have at least two instances". The DynamoDB equivalent of all three calls is one
CreateTable, and it contains no sizing decision at all:

{
  "TableName": "orders",
  "KeySchema": [
    {"AttributeName": "customerId", "KeyType": "HASH"},
    {"AttributeName": "orderId", "KeyType": "RANGE"}
  ],
  "AttributeDefinitions": [
    {"AttributeName": "customerId", "AttributeType": "S"},
    {"AttributeName": "orderId", "AttributeType": "S"}
  ],
  "BillingMode": "PAY_PER_REQUEST"
}

Where the crossover actually falls

Two db.r6g.large instances in us-east-1 on the Standard configuration list at
$0.26315 per instance-hour, so a 730-hour month is about $384 before a single
query, plus $0.20 per million I/O requests on top. That figure does not move with
traffic. It is what the cluster costs when nobody uses it.

DynamoDB on-demand in the same Region bills $0.125 per million read request units and
$0.625 per million write request units. An eventually consistent read of an item up to
4 KB costs half a read unit, so $384 of DynamoDB reads is roughly 6.1 billion of
them — about 2,300 reads a second, sustained, for the whole month. Priced as writes
instead, the same $384 buys about 615 million, or 234 a second, because a write unit
costs five times a read unit and covers 1 KB rather than 4 KB.

So the crossover sits at a few thousand reads a second for this cluster shape, and it
moves with item size: reads round up to the next 4 KB, so 12 KB items triple the read
cost and pull the crossover down by the same factor. Below it, DynamoDB's floor of zero
wins on arithmetic alone. Above it, provisioned instances start looking sensible again.
The DynamoDB pricing calculator runs this against
your own numbers.

What "MongoDB-compatible" guarantees, and what it does not

AWS's own claim is careful: DocumentDB "emulates the MongoDB 3.6, 4.0, 5.0, and 8.0
APIs on a purpose-built database engine", and "as a result, query plans and the output
of explain() may differ". Compatibility is per operator, and AWS publishes the list.
Currently documented gaps include $where and capped collections on every version,
$graphLookup on every version, and $lookup that supports uncorrelated but not
correlated subqueries.

The one that bites first is retryable writes. Drivers from MongoDB 4.2 enable them by
default and DocumentDB does not support them, so the connection string needs
retryWrites=false or the driver gets back
{"ok":0,"errmsg":"Unrecognized field: 'txnNumber'","code":9}. Wire compatibility
covers the protocol your driver speaks, and stops there. A DynamoDB migration makes
the same point louder by not offering the protocol in the first place.

Failover is the other thing that disappears. A DocumentDB cluster has one writer;
promotion "typically completes within 30 seconds", and AWS tells you plainly that "your
application should retry database connections in the event of a connection loss."
DynamoDB has no connection to lose and no writer to promote. Every operation is a
signed HTTPS request, so the reconnect logic, the read-preference routing and the
replica-lag reasoning all leave your codebase.

What does not leave is the ad-hoc query your team ran in mongosh whenever a customer
asked something. DynamoDB has no server-side joins or aggregates, and PartiQL adds
none. DynoTable's SQL Workbench is where those land:

SELECT status, COUNT(*) AS orders, SUM(total) AS revenue
FROM orders
WHERE customerId = 'acme'
GROUP BY status

It compiles to DynamoDB's native Query and Scan, planned against your real keys and
indexes, and does the grouping and the sums on the client. It supports INNER JOIN and
LEFT JOIN, GROUP BY, and COUNT/SUM. It adds no server-side capability to
DynamoDB, because nothing can; it removes the paging and rollup code you would
otherwise write every time someone asks a question you did not design a key for.

Working with DynamoDB

Once you've chosen DynamoDB, DynoTable is a desktop DynamoDB client
for browsing, editing, and querying your tables without the AWS Console. It reads
your standard AWS credentials, so your data stays in your account and in DynamoDB.
If you're coming from the MongoDB query-anything mental model, its
SQL Workbench covers the ad-hoc filtering and aggregation
you'd miss — real JOIN, GROUP BY, and aggregates, expressed within
DynamoDB's access-pattern rules.

Because DynamoDB has its own expression syntax rather than SQL or the MongoDB
query language, the free
DynamoDB Expression Builder helps you build
correct key conditions, filter expressions, and update expressions and copy them
straight into your SDK code. To sanity-check costs before you migrate, the
DynamoDB pricing calculator estimates
on-demand and provisioned capacity spend.

FAQ

Is DocumentDB the same as DynamoDB?
No. They are two separate AWS database services. DynamoDB is a serverless
key-value and document store with its own API, while Amazon DocumentDB is a
MongoDB-compatible document database that runs on a cluster of instances. They
share no query API and are provisioned, scaled, and priced differently.

Which is cheaper, DynamoDB or DocumentDB?
It depends on the workload, so there's no universal answer. DynamoDB bills
per request (on-demand) or per provisioned capacity plus storage, with no idle
instance cost — often cheaper for spiky or low-baseline traffic. DocumentDB bills
per instance-hour plus I/O, storage, and backup, which can be more cost-effective
for steady, high-throughput workloads on right-sized instances.

Does DynamoDB support the MongoDB API?
No. DynamoDB uses its own API (GetItem, Query, Scan, PutItem,
UpdateItem) and also supports PartiQL, a SQL-compatible query language. Amazon
DocumentDB is the AWS service that provides MongoDB API compatibility.

Related

• Learn the DynamoDB data types and single-table design before you model a table.
• Compare capacity modes in on-demand vs provisioned.
• Build queries fast with the free DynamoDB Expression Builder, then download DynoTable to work your tables.

References

• What is Amazon DynamoDB? — AWS DynamoDB Developer Guide
• DynamoDB service quotas (400 KB item size limit)
• DynamoDB on-demand capacity mode
• What is Amazon DocumentDB (with MongoDB compatibility)?
• Amazon DocumentDB quotas and limits (16 MB document size)
• Amazon DocumentDB serverless
• Amazon DocumentDB pricing

Last verified 2026-07-13 against the AWS DynamoDB and Amazon DocumentDB
developer guides. Amazon DocumentDB and MongoDB are trademarks of their
respective owners, referenced here for identification only.