DynamoDB Partitions and Scaling

DynamoDB automatically stores your data across multiple physical storage nodes called partitions. Understanding how partitions work explains why some DynamoDB tables perform exceptionally well and others hit unexpected speed limits — even with plenty of capacity.

What Is a Partition?

A partition is a physical slice of storage within DynamoDB's infrastructure. Think of your table as a pizza. Each partition is one slice. As your table grows, DynamoDB cuts the pizza into more slices and stores each slice on a separate physical machine. Each machine can serve reads and writes independently, which is how DynamoDB scales.

Partition Capacity

Each partition can handle:

• Up to 3,000 RCUs of read throughput per second
• Up to 1,000 WCUs of write throughput per second
• Up to 10 GB of data storage

When a partition exceeds any of these limits, DynamoDB automatically splits it into two partitions.

How DynamoDB Assigns Items to Partitions

DynamoDB runs your partition key value through a hash function to determine which partition holds that item. Items with similar partition key values often land on different partitions because the hash function deliberately spreads them out.

Partition Key Value → Hash Function → Partition Assignment
────────────────────────────────────────────────────────
"UserID: U001"    → Hash → Partition A
"UserID: U002"    → Hash → Partition C
"UserID: U003"    → Hash → Partition A
"UserID: U004"    → Hash → Partition B
"UserID: U005"    → Hash → Partition D

The hash function distributes keys evenly when keys have high cardinality (many unique values). Items that share the same partition key always go to the same partition.

Partition Scaling Triggers

DynamoDB creates a new partition when your table hits certain thresholds:

• A partition reaches 10 GB of data.
• Provisioned throughput needs exceed one partition's capacity (3,000 RCUs or 1,000 WCUs).

When DynamoDB splits a partition, it divides both the data and the throughput budget between the two new partitions.

Diagram: Partition Split Due to Data Growth

Initial State (1 partition):
┌─────────────────────────────────┐
│ Partition A (8 GB)              │
│ Items: U001–U500                │
└─────────────────────────────────┘

After growth past 10 GB → DynamoDB splits:
┌─────────────────────┐  ┌─────────────────────┐
│ Partition A1 (5 GB) │  │ Partition A2 (5 GB) │
│ Items: U001–U250    │  │ Items: U251–U500    │
└─────────────────────┘  └─────────────────────┘

The Hot Partition Problem

A hot partition occurs when most of your traffic concentrates on one partition while others sit idle. DynamoDB allocates capacity equally across all partitions, but if 90% of your traffic hits one partition, that partition gets overwhelmed while others are underused.

Example of a Hot Partition

Table: SalesEvents  (Partition Key: EventType)

Only two values: "FlashSale" and "Regular"
90% of reads hit "FlashSale"

Partition holding "FlashSale": Overloaded → Throttled
Partition holding "Regular":   Nearly idle → Wasted capacity

Even with 10,000 RCUs provisioned, performance suffers because
one partition cannot exceed 3,000 RCUs.

How to Avoid Hot Partitions

1. Use High-Cardinality Partition Keys

Choose attributes with many unique values — like UserID (UUID), OrderID, or DeviceID. This ensures even distribution across partitions.

2. Add Random Suffixes (Write Sharding)

If your data must use a low-cardinality key, append a random number to the partition key to create artificial distribution.

Without sharding:
  Partition Key: "FlashSale"
  → All traffic → 1 partition → hot

With sharding (suffix 1–10):
  "FlashSale_1", "FlashSale_2", ..., "FlashSale_10"
  → Traffic spreads across 10 partitions

To read all FlashSale items:
  Query all 10 partitions and combine results in application

3. Use DynamoDB Accelerator (DAX) for Read-Heavy Hot Keys

DAX is an in-memory cache for DynamoDB. Extremely popular items (like a trending product page) can be cached in DAX so that DynamoDB partitions receive fewer direct read requests. DAX is covered in the Design Patterns topic.

Adaptive Capacity

DynamoDB includes a feature called Adaptive Capacity that automatically boosts throughput to a hot partition temporarily by borrowing unused capacity from cooler partitions. This helps absorb short, unpredictable bursts.

Total provisioned: 1,000 WCUs across 4 partitions (250 each)

Partition A is hot: needs 400 WCUs
Partition B, C, D each need only 100 WCUs

Adaptive Capacity: shifts unused capacity from B/C/D to A
→ Partition A gets 400 WCUs temporarily
→ Avoids throttling for the burst period

Adaptive Capacity is not a substitute for good key design — it handles short spikes, not sustained imbalanced traffic.

Partitions Do Not Shrink

Once DynamoDB splits a table into more partitions, the number of partitions does not decrease even if traffic or data volume drops. This means throughput is divided among more partitions permanently. After a large sale event inflates your partition count, each partition has a smaller share of your provisioned capacity going forward.

This is one reason it is important not to over-provision capacity during temporary spikes — On-Demand mode handles spikes without the permanent partition side effect.

Estimating Partition Count

DynamoDB calculates the number of partitions needed based on provisioned throughput and data size:

Partitions from throughput = Ceiling(RCU / 3000) + Ceiling(WCU / 1000)
Partitions from storage    = Ceiling(Total GB / 10)
Actual Partitions          = Max of the two calculations

This estimate helps you understand how your provisioned capacity is distributed across partitions.

Summary