Start Here
SingleTable is a library of production-tested DynamoDB single-table design patterns - with full PK/SK designs, GSI strategies, and ElectroDB entity code. This page is the on-ramp.
26 posts live and growing.
This site assumes you know what DynamoDB is and have used it at least a little. If you're completely new - unfamiliar with partition keys, sort keys, or read capacity units - start with the fundamentals post first, then come back here.
Path 1: Know DynamoDB, new to single-table design
You've used DynamoDB with one table per entity. You've heard "single-table design" and want to understand it before committing to it.
- 1 When NOT to Use Single-Table Design
Read this before anything else. It'll tell you if single-table design is actually the right call for your situation - and save you from a painful migration if it isn't.
- 2 The 5 Most Common Single-Table Design Mistakes
The patterns that cause teams to abandon single-table design in frustration. Learn them before you design anything.
- 3 SaaS Multi-Tenant Pattern
The most complete worked example on the site. 10 access patterns, 3 GSIs collapsed to 1, full ElectroDB entity code. Read it end-to-end even if you're not building SaaS - the design principles apply everywhere.
- 4 ULIDs vs UUIDs vs Timestamps for Sort Keys
The sort key decision that affects every entity in your schema. Most schemas get this wrong and pay for it later.
Path 2: Looking for a specific pattern
You have a use case and want to see how someone else designed the schema.
Path 3: Deep-dive on a specific topic
You understand the basics and have a specific technical question.
Decision guides
Schema design
- ULIDs vs UUIDs vs Timestamps for Sort Keys →
- Sparse Indexes: Queues, Soft Deletes, Active-Only Views →
- Hot Partitions and Write Sharding (coming soon)
- Schema Migrations: The Guide Nobody Wrote →
- What Queries Your Schema Explicitly Doesn't Support →
- When Order Duplication Is and Isn't Acceptable →
- The 5 Most Common Single-Table Design Mistakes →
Operations & cost
- Cost Optimization: The 5 Levers That Actually Matter →
- On-Demand vs Provisioned: The Real Math (coming soon)
- Transactions vs Conditional Writes (coming soon)
- Pagination Done Correctly (coming soon)
- Idempotency Keys: Deduplicating Writes (coming soon)
- TTL: Soft Deletes, Expiry, and Archival (coming soon)
- Streams: Fan-Out, CDC, and Projections (coming soon)
- Tenant Isolation: Application-Layer vs IAM LeadingKeys →
Path 4: I've designed schemas before — what should I read?
You've shipped DynamoDB in production. You're here to pressure-test an existing design, spot anti-patterns, or prepare for a migration.
- 1 The 5 Most Common Single-Table Design Mistakes
The patterns that look fine until you hit scale or need a new access pattern. Read this first - if any sound familiar, you have a migration coming.
- 2 Cost Optimization: The 5 Levers That Actually Matter
If your bill is climbing, the fix is almost always schema-level. On-demand vs provisioned is a distraction - the real levers are item size, access patterns, and GSI projections.
- 3 Schema Migrations: The Guide Nobody Wrote
There's no ALTER TABLE in DynamoDB. This walks through migrating a live schema without downtime.
- 4 ElectroDB vs DynamoDB-Toolbox vs Dynamoose
On a different ORM and considering a switch before a migration? This is the comparison.
- 5 Hot Partitions and Write Sharding coming soon
The scaling issue you only hit in production. If you're seeing throttling on a partition that shouldn't be busy, this is why.
If you're rebuilding an existing schema, a review catches the issues before migration.
Send your access patterns and current schema. I'll return a full redesign with migration path, ElectroDB entity definitions, and trade-off analysis. Async, no calls required.
Request a schema review →Designing a schema and want a second pair of eyes?
Send your access patterns and entity list. I'll return the schema design with ElectroDB index definitions, GSI strategy, and trade-off analysis. 3–7 business days, no calls.
See schema review options →