Amazon DynamoDB Cheat Sheet

Updated 2026-05-15

Next Topic: Amazon RDS and Managed Cloud Databases Cheat Sheet

🧠Study flashcards on this topic96 cards · spaced repetition→

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, 96 flashcards. 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

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

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.
Partition key design	`CustomerId#Date` or hash suffix	• High-cardinality keys distribute load evenly • avoid low-cardinality keys like status fields which create hot partitions
Key overloading	`PK: USER#123` `PK: ORDER#456`	Generic key names (PK/SK) with entity-type prefixes allow storing multiple entity types in one table for single-table design.
Multi-attribute composite keys	Up to 4 partition + 4 sort keys	Native support for multi-attribute composite keys in GSIs (Nov 2025 feature) eliminates need for synthetic key concatenation.

Table 2: Capacity Modes

How you pay for throughput is one of the first and most consequential decisions in DynamoDB. On-demand mode scales automatically and bills per request — great for spiky or unknown traffic — while provisioned mode pre-allocates RCUs and WCUs for a lower cost on predictable workloads. The rest of the rows explain the moving parts that keep either mode running smoothly: auto scaling, burst capacity, and adaptive capacity that quietly absorbs hot partitions.

Mode	Example	Description
On-demand mode	Pay-per-request pricing	• Serverless capacity that automatically scales to workload demands • billed per read/write request without capacity planning • 2x previous peak instant burst available

The rest of this section is part of the full cheat sheet

Table 3: Item Operations

These are the bread-and-butter calls for working with single items — putting, getting, updating, and deleting by primary key. The subtleties matter more than they look: PutItem replaces an entire item while UpdateItem touches only specific attributes, and conditional writes, atomic counters, and optimistic locking are how you handle concurrency safely without a read-then-write race.

Operation	Example	Description
PutItem	`PutItem(item={PK, SK, data})`	• Creates new item or replaces entire existing item with same primary key • overwrites all attributes (not partial update).

The rest of this section is part of the full cheat sheet

Table 4: Conditional and Filter Expressions

Expressions are DynamoDB's small query language for testing and filtering item data, and the same building blocks power conditional writes and filter expressions alike. You get existence checks like attribute_exists, comparison operators, and functions such as begins_with, between, contains, and size — the toolkit for "only write if" guards and for narrowing results after a Query or Scan.

Expression	Example	Description
attribute_exists	`attribute_exists(Email)`	• Function checks if an attribute exists on the item • commonly used in conditional writes to prevent overwrites

The rest of this section is part of the full cheat sheet

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.
Partition key design	`CustomerId#Date` or hash suffix	• High-cardinality keys distribute load evenly • avoid low-cardinality keys like status fields which create hot partitions
Key overloading	`PK: USER#123` `PK: ORDER#456`	Generic key names (PK/SK) with entity-type prefixes allow storing multiple entity types in one table for single-table design.
Multi-attribute composite keys	Up to 4 partition + 4 sort keys	Native support for multi-attribute composite keys in GSIs (Nov 2025 feature) eliminates need for synthetic key concatenation.

Table 2: Capacity Modes

Mode	Example	Description
On-demand mode	Pay-per-request pricing	• Serverless capacity that automatically scales to workload demands • billed per read/write request without capacity planning • 2x previous peak instant burst available

Table 3: Item Operations

Operation	Example	Description
PutItem	`PutItem(item={PK, SK, data})`	• Creates new item or replaces entire existing item with same primary key • overwrites all attributes (not partial update).

Table 4: Conditional and Filter Expressions

Expression	Example	Description
attribute_exists	`attribute_exists(Email)`	• Function checks if an attribute exists on the item • commonly used in conditional writes to prevent overwrites