MediumExperience level: 3-5 years · 8-15 years5 min read

DynamoDB Partition Key — Hot Partitions & Key Design

Reviewed by Gurusankar M. · Updated Aug 24, 2026

Asked inAmazonGoogleMicrosoft
#dynamodb#partition key#sort key#hot partition#throughput#scaling
Report issue

Short Answer

DynamoDB distributes data across partitions by the partition key's hash. If many requests target one key (or a low-cardinality key), that partition gets 'hot' — throttling even when total capacity is fine. Choose a high-cardinality, evenly-accessed key; add a suffix/sharding for hot keys.

On this page

Concept Made Simple

Coffee Chat Question

“How does the DynamoDB partition key affect performance, and what is a hot partition?”

Remember It Faster

Mind Map Answer

The partition key (hash key) is the attribute DynamoDB hashes to decide which physical partition stores an item. It's how DynamoDB scales horizontally — every item's partition key hash maps to one of many partitions, so read/write load spreads across the fleet instead of hitting a single server. There's no ad-hoc query flexibility like SQL: you look up by partition key (and optionally a sort key or GSI), so access patterns have to be known before the table is designed.

Partition key
hashed → decides the partition
Hot partition
skewed access → throttling
Fix
high-cardinality key / write sharding
Partition KeySort Key
Required?AlwaysOptional
DeterminesWhich partition stores the item (hash)Item order/uniqueness within that partition
Query supportExact match only (=)Range, begins_with, between
UniquenessMust be unique alone, unless paired with a sort keyPK + SK together must be unique

A concrete before/after: a table partitioned by status (3 values — pending/shipped/delivered) versus the same table repartitioned by userId (millions of distinct values).

Bad key: status (3 values)Good key: userId (millions of values)
Distinct key values3~1 per user — millions
Where traffic landsEvery request collapses onto one of 3 partitionsRequests spread across many partitions
Per-partition ceilingHit almost immediately, no matter total provisioned capacityEach partition stays well under AWS's per-partition throughput ceiling
Result at scaleThrottled (ProvisionedThroughputExceededException) even with capacity to spare table-wideThroughput scales close to linearly with provisioned capacity

This doesn't mean low-cardinality attributes like status are unusable — they just can't be the partition key. Keep the high-cardinality id (e.g. orderId) as the partition key, and put status in a sort key or a Global Secondary Index instead. You still get an efficient "all orders with status = shipped" query via the GSI, but writes spread across partitions by orderId instead of collapsing onto one of three.

Adaptive capacity helps, but only up to a point. DynamoDB continuously monitors traffic per partition and, when it detects a hot partition, transparently isolates that partition's keys and boosts throughput toward it — instantly for isolated hot keys since 2019, without any table resizing or manual intervention. What it can't do is rescue a pathologically low-cardinality key design: adaptive capacity can boost one hot partition's share of the table's total provisioned throughput, but it can't manufacture throughput the table doesn't have, and a single partition is still bounded by DynamoDB's documented per-partition limits (up to 3,000 read request units and 1,000 write request units per second), so a design that funnels traffic through a handful of key values hits that ceiling however the table is provisioned. Adaptive capacity buys headroom for uneven access on an otherwise reasonable key; it's not a substitute for high-cardinality key design.

You don't calculate or configure the number of partitions — DynamoDB manages it. It places each item by hashing its partition key, and splits partitions automatically as data grows or traffic rises (on-demand tables also adapt to traffic on their own). The figure worth designing around is the per-partition limit above. As a rough back-of-envelope check, peak writes per second ÷ 1,000 and peak reads per second ÷ 3,000 give a lower bound on how many evenly-used partition key values you need in play at once. It's an estimate for judging key spread, not a formula DynamoDB exposes or guarantees.

Time-based keys are the sneaky version of a low-cardinality key — the partition key itself may have plenty of distinct values over the table's lifetime (2026-09-01, 2026-09-02, ...), so it doesn't look low-cardinality at a glance. The problem is access pattern, not key design: almost all reads and writes target today's date, so at any given moment traffic still collapses onto whichever single partition represents "now," while every other date's partition sits idle. The fix is the same write-sharding idea from above, applied proactively: suffix the date with a shard number (2026-09-15#3) so "today" is spread across multiple partitions even while it's the only date anyone's writing to, rather than discovering the hot-partition problem only once a single calendar day's traffic exceeds one partition's throughput ceiling.

Learn by Doing

Hands-on Keyboard

java
// Write sharding: spread a hot partition key across N logical shards
// so no single physical partition absorbs all the write traffic.
int shardCount = 10;
String hotKey = "sensor-42";                       // naturally low-cardinality / bursty
int shard = ThreadLocalRandom.current().nextInt(shardCount);
String shardedPk = hotKey + "#" + shard;             // e.g. "sensor-42#7"

PutItemRequest put = PutItemRequest.builder()
    .tableName("Readings")
    .item(Map.of(
        "pk", AttributeValue.fromS(shardedPk),       // spread across 10 partitions
        "sk", AttributeValue.fromS(Instant.now().toString()),
        "value", AttributeValue.fromN(String.valueOf(reading))))
    .build();
ddb.putItem(put);

// Reads must now fan out across all shards and merge results client-side —
// that's the cost of sharding: writes get cheap, reads get more complex.
List<QueryRequest> shardQueries = IntStream.range(0, shardCount)
    .mapToObj(i -> QueryRequest.builder()
        .tableName("Readings")
        .keyConditionExpression("pk = :pk")
        .expressionAttributeValues(Map.of(":pk", AttributeValue.fromS(hotKey + "#" + i)))
        .build())
    .toList();
Output
10 physical partitions absorb the write load instead of 1; queries fan out and merge.

Think Beyond the Expected

What If?

A table partitioned by 'status' (only 3 values) throttles under load — why and fix?

Only 3 partition-key values means traffic concentrates on 3 partitions → hot partitions and throttling regardless of provisioned capacity. Use a high-cardinality key (e.g. entity id) and put status in a GSI/sort key, or shard the hot key with a suffix.

Real World

Hot-partition throttling from low-cardinality or skewed keys is the #1 DynamoDB performance pitfall; key design (and write sharding for hotspots) is the fix, not raising capacity. The write-sharding pattern above is the standard escape hatch when an attribute is inherently hot (a trending item, a single IoT sensor, a viral post) and can't simply be swapped for a different key.

Interviewer's Expectation

Keywords they're listening for:

  • hash-based distribution
  • hot partition from skew/low cardinality
  • high-cardinality key
  • write sharding
  • adaptive capacity limits

Common Mistakes

  • Low-cardinality partition keys
  • Time-based keys causing hot 'current' partition
  • Raising capacity to fix skew (doesn't)

Best Practices

  • Choose high-cardinality, evenly-accessed keys
  • Shard hot keys with a suffix
  • Design keys around access patterns

Follow-up Questions

  1. What is a DynamoDB partition key?
  2. How does DynamoDB distribute data across partitions?
  3. What makes a partition key 'high-cardinality', and why does it matter?
  4. Partition key vs sort key — what's the difference?
  5. How does adaptive capacity help (and not)?
  6. How do you shard a hot write key?

References

Continue Learning with AI

Take this question deeper with your favourite AI assistant. Pick a depth, copy the prompt, or open it directly — AI is your learning companion, not a shortcut.

Plain-language foundations

I'm preparing for a software engineering interview and want to understand this from scratch, as a beginner.

Topic: DynamoDB (AWS)
Interview question: "How does the DynamoDB partition key affect performance, and what is a hot partition?"

Please:
1. Explain the core idea in simple, plain language, using an everyday analogy.
2. Define any technical terms you use.
3. Walk through one small, concrete example.
4. Finish with a single sentence I can easily remember.

Keep the tone friendly and assume I'm new to this topic.
Open inChatGPTGeminiClaude

Was this answer helpful?

Affiliate links

Tools for Your Developer Workspace

Equipment for a comfortable, productive setup.

As an Amazon Associate I earn from qualifying purchases.