Amazon DynamoDB Cheat Sheet

Updated 2026-05-15

Next Topic: Amazon RDS and Managed Cloud Databases Cheat Sheet

Amazon DynamoDB is AWS's fully managed NoSQL database service offering single-digit millisecond performance at scale, supporting both key-value and document data models across provisioned or on-demand capacity modes. Unlike relational databases, DynamoDB is designed around access patterns rather than normalized schemas, where tables are identified by primary keys (partition key alone or partition + sort key), and queries are optimized through carefully designed indexes rather than joins. Single-table design, where multiple entity types coexist in one table using overloaded keys and GSIs, is a core pattern for minimizing costs and maximizing performance — understanding partition key distribution, read/write capacity units (RCU/WCU), and the distinction between Query (efficient, key-based) and Scan (expensive, full-table) operations is fundamental to building cost-effective, high-performance applications.

What This Cheat Sheet Covers

This topic spans 20 focused tables and 145 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Table Creation and Primary KeysTable 2: Capacity ModesTable 3: Item OperationsTable 4: Conditional and Filter ExpressionsTable 5: Query and Scan OperationsTable 6: Global Secondary Indexes (GSI)Table 7: Local Secondary Indexes (LSI)Table 8: DynamoDB StreamsTable 9: Batch and Transaction OperationsTable 10: DynamoDB Accelerator (DAX)Table 11: Single-Table Design PatternsTable 12: Update Expressions and Attribute OperationsTable 13: PartiQL and Advanced QueriesTable 14: Read Consistency and Data DurabilityTable 15: TTL, Backup, and RecoveryTable 16: Global Tables and Multi-RegionTable 17: Encryption and SecurityTable 18: Python boto3 SDKTable 19: Performance OptimizationTable 20: Cost Optimization

Table 1: Table Creation and Primary Keys

Everything in DynamoDB hangs off the primary key, so getting it right is the whole game. You either use a single partition key or pair it with a sort key to store and range-query related items together, and the rows here show the patterns that make single-table design work — hierarchical sort keys, generic overloaded keys, and high-cardinality designs that spread load evenly instead of creating hot partitions.

Concept	Example	Description
Partition key (simple primary key)	`UserId`	• Single-attribute primary key that uniquely identifies each item • DynamoDB distributes data across partitions based on the partition key hash
Composite primary key	`PK: UserId` `SK: OrderDate`	• Partition key + sort key combination allowing multiple items with the same partition key • items are stored together and sorted by sort key for range queries
Composite sort key	`SK: COUNTRY#USA#STATE#CA#CITY#SF`	Hierarchical sort key pattern using delimiters to enable querying at any hierarchy level with `begins_with` conditions.

Table 1: Table Creation and Primary Keys

Concept	Example	Description
Partition key (simple primary key)	`UserId`	• Single-attribute primary key that uniquely identifies each item • DynamoDB distributes data across partitions based on the partition key hash
Composite primary key	`PK: UserId` `SK: OrderDate`	• Partition key + sort key combination allowing multiple items with the same partition key • items are stored together and sorted by sort key for range queries
Composite sort key	`SK: COUNTRY#USA#STATE#CA#CITY#SF`	Hierarchical sort key pattern using delimiters to enable querying at any hierarchy level with `begins_with` conditions.