DynamoDB Single-Table Design Guide
A library of production-tested DynamoDB schema designs - full PK/SK structures, GSI strategies, and ElectroDB entity code. This page explains the method, then points you at the right pattern.
47 posts live and growing.
What DynamoDB single-table design means
Relational modelling starts with entities and works outward to queries. DynamoDB runs the other way. You write down every query the application makes, then design partition and sort keys that answer them. One table holds users, projects, invoices and everything else, kept apart by how their keys are built.
The gain is that related items share a partition. A project and its last fifty events come back in one query instead of a join. The cost is that a query you never planned for may need a new index, or a migration.
So the work happens before any data is live. Once you pick a partition key and write a few million items behind it, changing that key means rewriting all of them.
What you decide, in order
- 1. The access patterns. Write each one as a sentence: "get all invoices for a tenant, newest first." If you cannot write the sentence, you cannot design the key. This list is the specification, and it is worth more than any diagram.
- 2. The primary key. The partition key decides what sits together; the sort key decides the order and what ranges you can slice. Most schemas that go wrong went wrong here - see ULIDs vs UUIDs vs timestamps and the five common mistakes.
- 3. The indexes. Every access pattern the primary key cannot serve needs a GSI, a reshaped sort key, or duplication. Reach for the GSI last: GSI vs sort key, sparse indexes, and how to cut the count.
- 4. The write guarantees. Decide where you need atomicity and what it costs - conditional writes vs transactions and idempotency keys.
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
- When NOT to Use Single-Table Design →
- Single-Table vs Table-Per-Tenant →
- DynamoDB Single-Table vs Multi-Table Design →
- DynamoDB vs Postgres for E-Commerce →
- DynamoDB vs Postgres for SaaS →
- DynamoDB vs Postgres for Chat and Messaging →
- When to Add a GSI vs Reshape Your Sort Key →
- DynamoDB Too Many GSIs: How to Reduce Them →
- ElectroDB vs DynamoDB-Toolbox vs Dynamoose →
Schema design
- ULIDs vs UUIDs vs Timestamps for Sort Keys →
- Sparse Indexes: Queues, Soft Deletes, Active-Only Views →
- Hot Partitions and Write Sharding →
- 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 →
- How to Query Without Scanning →
- Adding an Access Pattern After Launch →
- Composite Sort Key begins_with Not Working →
- ElectroDB: Collection vs Entity →
Operations & cost
- Cost Optimization: The 5 Levers That Actually Matter →
- On-Demand vs Provisioned: The Real Math →
- Transactions vs Conditional Writes →
- Pagination Done Correctly →
- Idempotency Keys: Deduplicating Writes →
- TTL: Soft Deletes, Expiry, and Archival →
- Streams: Fan-Out, CDC, and Projections →
- 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
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 →Common questions
What is DynamoDB single-table design?
Single-table design stores every entity type - users, orders, invoices - in one DynamoDB table, separated by how their partition and sort keys are built. You start from the queries the application needs and design keys that answer them, rather than starting from entities as you would in a relational database.
Is single-table design always better than multiple tables?
No. It pays off when entities are queried together and you want one round trip instead of several. If your entities are genuinely unrelated, or your access patterns change often and unpredictably, separate tables are simpler to operate and easier to change.
How many GSIs does a single-table schema need?
Most schemas need one to three. If you are past five, the usual cause is treating every new access pattern as a new index instead of reshaping the sort key or overloading an existing GSI. A high GSI count also multiplies write cost, since every indexed write is billed again per index.
Can you change a DynamoDB schema after launch?
Yes, but there is no ALTER TABLE. You add the new key attributes to items as they are written, backfill the rest with a scan-and-update job, then switch reads over once coverage is complete. Adding an access pattern is routine; changing an existing partition key means rewriting every item.
Do you need ElectroDB to do single-table design?
No, the raw AWS SDK is enough. ElectroDB mainly removes the hand-written key construction and the type errors that come with it, which is where most single-table bugs start. The design work is identical either way.
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 →