DynamoDB Is Not a Relational Database
This is the first mistake developers from the SQL world make. DynamoDB requires you to think about your access patterns before designing your tables.
1. Start with Access Patterns
Before creating a table, list every query your application needs:
- Get a user by ID
- List a user's orders
- Find orders by status and date
This is your starting point. Not the data model.
2. Single-Table Design: When to Use It
Single-table design puts all your entities in one DynamoDB table. It's powerful but not always necessary.
Use it when:
- You have 1-N relationships frequently queried together
- You want to minimize the number of requests
- Your team is comfortable with the pattern
Avoid it when:
- Your team is new to DynamoDB
- Entities are rarely queried together
- Code complexity outweighs the performance gain
3. GSI: Your Secret Weapon
Global Secondary Indexes let you query data from different angles without duplicating it.
- Limit yourself to 5 GSIs per table (AWS hard limit: 20)
- Each GSI has its own read/write cost
- Use sparse indexes to save money
4. Capacity Management
- On-Demand: for unpredictable loads or early-stage projects
- Provisioned + Auto-Scaling: for stable, predictable loads
- Reserved Capacity: -50% with 1 or 3-year commitment
5. Essential Monitoring
Always watch:
- ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits
- ThrottledRequests: must never be > 0 in production
- SuccessfulRequestLatency: aim for < 10ms at P99
Conclusion
DynamoDB is extremely performant when used correctly. The trap is approaching it like a SQL database. Take the time to model properly, and you'll have a database handling millions of requests daily for a few dollars.
Need help with DynamoDB? Contact me.