Amazon DynamoDB
DynamoDB
You need a NoSQL database that can handle arbitrary write scales with consistent single-digit millisecond latency.
Reach for it when
- Storing session state, user shopping carts, or game state profiles that require rapid lookups.
- Building serverless web backends where database connections scale instantly without connection pool exhaustion.
- Storing audit logs or event feeds that can be automatically cleaned up using TTL configurations.
Do not reach for it when
- Running complex analytical queries requiring multi-table joins or aggregation functions — use RDS or Athena instead.
- Storing large blobs or document files exceeding 400KB in size — store the files in S3 and reference the path instead.
- Migrating legacy applications that depend heavily on SQL syntax and foreign key constraints — use RDS instead.
Alternatives, and how to choose
| Service | Pick it instead when |
|---|---|
| RDS | Choose it when you need SQL compliance, complex relational schemas, and transaction joins. |
| DocumentDB | Choose it when migrating MongoDB workloads that require native MongoDB API compatibility. |
How you pay
- The model
- Pay per Read and Write Request Units (on-demand) or per provisioned capacity unit, plus storage fees.
- The line item that surprises people
- Leaving tables in provisioned mode with high scaling limits accumulates billing even if zero queries are executed.
What trips people up
- A single item write cannot exceed 400KB; attempting to write larger items will fail with a ValidationException.
- Failing to choose a high-cardinality partition key leads to hot partitions, which throttle read and write throughput.
- Query operations can only search by primary keys; searching by other attributes requires slow and expensive scan operations.
Verify the live service
This page is a concept reference. Cost models are qualitative; confirm the current offering, Region and pricing before deploying.