DynamoDB Cheat Sheet

How to use this DynamoDB cheat sheet

GetItem fetches one item by full primary key; Query reads items sharing a partition key with optional SK conditions. Scan reads entire table—avoid in production except migrations or analytics with filters.

AWS SDK v3 uses command objects (GetItemCommand, QueryCommand) with DynamoDBClient. On-demand vs provisioned capacity affects cost; single-table design colocates related entities with composite keys and overloaded GSIs.

Quick DynamoDB example

import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient, GetCommand, QueryCommand } from '@aws-sdk/lib-dynamodb';

const client = DynamoDBDocumentClient.from(new DynamoDBClient({ region: 'us-east-1' }));

const user = await client.send(new GetCommand({
  TableName: 'App',
  Key: { PK: 'USER#123', SK: 'PROFILE' },
}));

const orders = await client.send(new QueryCommand({
  TableName: 'App',
  KeyConditionExpression: 'PK = :pk AND begins_with(SK, :sk)',
  ExpressionAttributeValues: { ':pk': 'USER#123', ':sk': 'ORDER#' },
}));

PK/SK & Access Patterns

GetItem, Query & Scan

GSI & SDK v3 Commands

Capacity & Single-Table Patterns

UpdateItem with optimistic locking

await client.send(new UpdateCommand({
  TableName: 'App',
  Key: { PK: 'USER#1', SK: 'PROFILE' },
  UpdateExpression: 'SET #v = :newV, #version = :next',
  ConditionExpression: '#version = :current',
  ExpressionAttributeNames: { '#v': 'name', '#version': 'version' },
  ExpressionAttributeValues: { ':newV': 'Ada', ':next': 2, ':current': 1 },
}));

ConditionExpression fails with ConditionalCheckFailedException if version mismatch.

Batch write with retry unprocessed

import { BatchWriteCommand } from '@aws-sdk/lib-dynamodb';
let request = { RequestItems: { App: puts } };
do {
  const res = await client.send(new BatchWriteCommand(request));
  request = { RequestItems: res.UnprocessedItems };
} while (Object.keys(request.RequestItems).length);

Exponential backoff on UnprocessedItems for throttling.

Single-table entity types

// Same table, different entities
{ PK: 'USER#42', SK: 'PROFILE', name: 'Ada', type: 'User' }
{ PK: 'USER#42', SK: 'ORDER#1001', total: 99, type: 'Order' }
{ PK: 'ORDER#1001', SK: 'METADATA', status: 'SHIPPED', type: 'OrderMeta' }

Design keys for every query before creating the table—GSIs are costly to change later.

Common mistakes

• Using Scan where Query with a designed PK would suffice.
• FilterExpression thinking it reduces RCUs—it filters after the read.
• Creating a GSI for every ad-hoc query instead of modeling access patterns upfront.
• Storing large blobs in DynamoDB instead of S3 with a pointer attribute.

Key takeaways

• Design PK/SK and GSIs from access patterns, not from relational table shapes.
• Prefer Query and GetItem; treat Scan as a last resort.
• Use DocumentClient and SDK v3 commands for cleaner Node.js code.
• Single-table design with prefixed keys keeps related data queryable in one round trip.