Backend7 min read

DynamoDB

Design and query DynamoDB at scale - single-table design, partition keys, GSIs, query patterns, DynamoDB Streams, and cost optimization.

DynamoDBAWSNoSQLDatabaseSingle Table Design

skill: DynamoDB category: Backend tags: [DynamoDB, AWS, NoSQL, Database, Single Table Design] readingTime: 7

DynamoDB is not a replacement for relational databases - it's a fundamentally different tool optimized for single-digit millisecond reads at any scale. Its limitations (no joins, no arbitrary queries) force you to design data access patterns upfront. Think in access patterns first, table design second.

Workflow

Design access patterns before modelingDynamoDB query design starts with your access patterns - unlike SQL where you define schema then write queries. Every query pattern needs a key or index.
Create and query with AWS SDKDynamoDB's SDK uses low-level attribute maps. Use the Document Client which handles JavaScript ↔ DynamoDB type marshaling automatically.
Design Global Secondary IndexesGSIs enable queries on non-primary-key attributes - each GSI is a separate table maintained automatically by DynamoDB.
Handle updates atomicallyUpdateExpression modifies specific attributes atomically - no read-modify-write cycle needed, preventing race conditions.
Stream changes with DynamoDB StreamsDynamoDB Streams captures all write operations as an ordered stream - enabling event-driven architectures and cross-region replication.

Output Format

DynamoDB: single-table design with composite keys, GSIs for query flexibility, UpdateExpression for atomic writes, and Streams for event sourcing.

Table: PK (partition) + SK (sort) - single table
Access patterns → key design → GSI for secondary queries
Query: KeyConditionExpression, begins_with, between
Update: SET/REMOVE/ADD with ConditionExpression
Streams → Lambda → downstream processing

Examples

Input

Output

Edge Cases & Gotchas

Hot partitions - All writes to PK: USER#top_user create a hot partition bottleneck. Distribute writes by adding a random suffix (shard key) to the partition key.
Item size limit - Each DynamoDB item is limited to 400KB. For large documents, store the item in S3 and only store the S3 key in DynamoDB.
GSI consistency - GSIs are eventually consistent - a write may not be visible in a GSI query for milliseconds. Use the base table for strongly consistent reads.
TransactWrite limits - DynamoDB transactions support up to 100 items across 10 tables. For more, implement saga pattern or use FIFO SQS + idempotent processing.

When to Break These Rules

Use PostgreSQL instead of DynamoDB when your access patterns are varied and unpredictable - SQL's flexibility beats DynamoDB's key-value constraints.
Use Redis instead of DynamoDB for caching, real-time leaderboards, or session storage - lower latency and better data structure support.

Reference Files

https://docs.aws.amazon.com/amazondynamodb/
https://www.dynamodbguide.com/