DynamoDB
AWS's fully-managed key-value/document database that scales horizontally by partitioning on a partition key. It offers single-digit-ms latency at any scale with provisioned or on-demand throughput. You design for the access patterns, not the data.
- High-scale key-value/document access with known patterns.
- Serverless apps wanting zero DB ops.
- Ad-hoc querying, joins, or complex aggregations.
- Items > 400KB or rich relational modeling.
Definition
DynamoDB stores items (up to 400KB) in tables partitioned by a partition key, optionally sorted by a sort key. Throughput is provisioned (RCU/WCU) or on-demand. Supports secondary indexes (GSI/LSI), streams, TTL, and transactions across up to 100 items.
Why it exists
Relational DBs are hard to scale horizontally for simple key lookups at huge volume. DynamoDB removes capacity planning and ops for key-value access patterns, trading query flexibility for predictable scaling.
How it works
Hash the partition key to assign items to partitions; throughput and storage spread across partitions. Queries are by key (or key prefix + sort conditions). GSIs enable alternate access patterns but cost extra throughput and have eventual consistency. Streams capture changes for CDC.
Scaling limits
Only key-based access patterns (no joins, limited ad-hoc queries). 400KB item cap. Hot partitions throttle if one key is hammered. GSIs are eventually consistent and have their own throughput. No cross-table joins.
Cost shape
Provisioned RCU/WCU or on-demand per-request + storage + backups. Blow-ups: hot keys, over-provisioned capacity, GSI reads/writes, and large item sizes multiplying write costs.
Alternatives
- PostgreSQL — Full query flexibility but you manage scaling.
- Cassandra — Similar wide-column model, self-hosted, tunable consistency.
Failure modes
- Hot partition throttling.
- GSI write amplification.
- Modeling for data, not access patterns, leading to scans.