Summary
DynamoDB automatically partitions tables across internal shards using the partition key as a shard discriminator. Adaptive capacity redistributes throughput across partitions automatically, but partition key design remains critical for avoiding hot partitions.
Evidence
- ·DynamoDB partitions tables automatically based on partition key hash: no manual shard management
- ·Each DynamoDB partition has a throughput ceiling (~3,000 RCU + 1,000 WCU per partition)
- ·Adaptive capacity (2019) allows popular partitions to burst above their allocation up to the table limit
- ·AWS re:Invent 2021 "DynamoDB Deep Dive" documents partition splitting behavior and hot partition mitigation
- ·Global tables replicate across regions using DynamoDB's internal sharding layer
Operational Context
- ·Partition key cardinality must be high: status, country, and boolean fields cause severe hot partition issues
- ·{'Write sharding': 'append a random suffix (1-10) to the partition key distributes writes across 10 logical partitions'}
- ·Monitor CloudWatch ConsumedWriteCapacityUnits per partition key prefix to detect hot partitions
Tradeoffs
- ·Write sharding for hot keys requires scatter-gather reads to reassemble results across partitions
- ·Adaptive capacity does not eliminate hot partition limits: it only allows temporary bursting
- ·DynamoDB partition splits are transparent but irreversible: a split table has permanent overhead for low-traffic keys
Evidence grounding
Grounded, 5 supporting itemsDynamoDB's partitioning model is extensively documented in AWS documentation and re:Invent talks. Adaptive capacity (2019) changed the hot partition behavior significantly and is well-documented.