DynamoDB

Key Design

• Partition key determines data distribution—high-cardinality keys spread load evenly
• Hot partition = one key gets all traffic—use composite keys or add random suffix
• Sort key enables range queries within partition—design for access patterns
• Can't change keys after creation—model all access patterns before creating table

Query vs Scan

• Query uses partition key + optional sort key—O(items in partition), always prefer
• Scan reads entire table—expensive, slow, avoids indexes; almost never correct
• "I need to filter by X" usually means missing GSI—add index, don't scan
• FilterExpression applies AFTER read—still consumes full read capacity

Global Secondary Indexes