Key-value at any scale · Chapter 1 of 2
How DynamoDB keys locate your data
Your database key schema is your primary query interface, and choosing the wrong partition key leads to hot partitions and serverless scalability limits.
FoundationsBuilds the idea from nothing. No prior AWS assumed.
Understanding primary and composite keys
How does the choice of primary key restrict how you query a table?
Schema design uses date string "YYYY-MM-DD" as Partition Key.
- 01
The partition key query constraint
In DynamoDB, you cannot use SQL queries with arbitrary where clauses. You must query records using the partition key, which DynamoDB hashes to determine the physical partition where the data is stored.
- 02
Composite keys for complex relationships
To support more patterns, you can combine a partition key with a sort key. This composite key allows you to query a single partition and retrieve records sorted by the sort key value.
- 03
The truth about single table design
Single-table design packs unrelated entity types into one table by using generic key names like PK and SK. While it minimises table count, it increases code complexity, makes manual data exploration difficult, and is usually the wrong choice for teams starting out.
Check yourself
Why does DynamoDB require a partition key for every query?
Under the hoodThe same thing from underneath: limits, failure modes, numbers.
Partition limits and the hot partition threat
What happens when a single partition receives too much read or write traffic?
Schema design uses date string "YYYY-MM-DD" as Partition Key.
- 01
The mechanics of a hot partition
A physical partition has throughput ceilings for reads and writes. If your application sends thousands of queries to the same partition key, that partition becomes hot, and DynamoDB throttles the requests.
- 02
Distributing keys to avoid throttling
To prevent hot partitions, you must choose a partition key with high cardinality, such as a user ID or order ID. Avoid keys with low cardinality, like a status field or country code.
- 03
Item size and partition split limitations
DynamoDB limits the maximum size of a single item. If your access pattern requires appending data to a single record indefinitely, you will hit the item size ceiling, forcing a database refactor.
The numbers
- Maximum item size
- 400 KBThe absolute limit for a single item, including attribute names and binary data.
- Partition read capacity ceiling
- 3,000 RCUThe maximum Read Capacity Units a single physical partition can support before throttling.
- Partition write capacity ceiling
- 1,000 WCUThe maximum Write Capacity Units a single physical partition can support before throttling.
- Partition storage limit
- 10 GBA single partition holds up to 10 GB of data before DynamoDB automatically splits it.
Check yourself
An application writes order records to a DynamoDB table using the current date (YYYY-MM-DD) as the partition key. Why is this a poor design?
Official references & further reading
These lessons simplify selected behaviors for learning. Verify current service limits, Region support and production requirements with the official references. Experiments describe their own assumptions.
Report an error or suggest a clearer explanation →