The quickest path to failure is using DynamoDB as a conventional database. And here is the way to think about it.
Introduction
It is technically right to refer to DynamoDB as a database, and practically wrong.
It is a fight to postgres, MySQL or even MongoDB to treat DynamoDB like a database. When you treat it as a distributed system whose rules are stringent, it turns out to be one of the most powerful tools that AWS has to offer.
It is a post about thinking about DynamoDB rather than querying it.
The Mental Model that Busters DynamoDB.
Most failures start here:
- "I'll normalize later"
- I will put in this access pattern later.
- "I'll just scan for now"
- "Indexes will fix it"
This is the thinking in relationships applied to a system that does not enrich flexibility.
DynamoDB's Real Contract
DynamoDB guarantees the following three things:
- Latency of scale in the single-digit milliseconds.
- Large-scale horizontal scalability.
- Fully managed operations
What it does not promise:
- Arbitrary queries
- Joins
- Ad-hoc analytics
- Query flexibility
As soon as you believe this, it just falls into place.
The Patterns of Access Are the Schema.
In DynamoDB:
Your pattern of access is your schema.
You should know before you put a single line of code:
- How items are written
- How they are read
- How they are updated
- How they are deleted
Should you find a new access pattern later then you are redesigning and not refactoring.
Partition Keys: The Actual Performance Limit.
Why Partition Keys Matter
- The distribution of data is on a physical partition key basis.
- Performance is killed by hot partitions.
- Distribution of traffic must be distributed evenly.
Common Mistakes
- Using userId blindly
- Using timestamps alone
- Low-cardinality keys
Better Patterns
- Composite keys
- Prefixed keys (USER#123)
- On-demand sharding based on hash.
Sort Keys Are to Model the Time and Hierarchy.
Sort keys let you:
- Model time series
- Group related entities
- Query ranges efficiently
Used well, they replace:
- ORDER BY
- LIMIT
- Many relational joins
when they are not well used they are useless.
Single-Table Design Is Non- Optional(At Scale).
There is nothing like single-table design. It is an effects of the physics of DynamoDB.
Why Multiple Tables Fail
- There are no cross-table queries.
- Transactions are limited
- Anyway, duplication of data becomes inevitable.
The capability of the Single-Table Design.
- Predictable queries
- Lower latency
- Lower cost
- Fewer indexes
Not Free (Nor is a Backup Plan) GSIs.
Global Secondary Indexes:
- Duplicate your data
- Double your write costs
- Add delay in the introduction of consistency.
In case your design relies on GSIs, then you have your base table incorrect.
Use GSIs to:
- Secondary access patterns.
- Not to rescue missing ones
Reads Are Cheap-- Writes Are your Bread and Butter.
The majority of DynamoDB cost surprises are brought about by:
- Overwriting large items
- High write amplification
- GSI fan-out
Design write effectiveness first, read effectiveness second.
Modeling (Conceptual) in the 2013-2016 Budget.
Instead of:
Users;
Orders;
OrderItems;
Think:
PK = USER#123
SK = PROFILE
PK = USER#123
SK = ORDER#2026-01-01
PK = USER#123
SK = ORDER#2026-01-01#ITEM#1
This is not denormalization this is deliberate copying.
When You Do Not Need DynamoDB.
Be honest. The DynamoDB is not the optimal choice when:
- Queries are unpredictable
- You need ad-hoc filtering
- You are not aware of pattern of access.
- You need complex joins
Use Postgres. Seriously.
DynamoDB + Next.js: Its Strengths.
DynamoDB is ideal in situations where:
- Access patterns are known
- The APIs are slender and focused.
- You require bounded latency.
- You are scaled by users, not queries.
Especially strong for:
- Auth-related data
- User activity feeds
- Metadata storage
- Event logs
Final Take
DynamoDB embraces an upfront way of thinking and penalizes improvisation.
It will counter-attack you in case you create it in the form of a database. When you develop it as a distributed system, it will grow even more than most teams ever require.
DynamoDB isn't hard. Bad habits of relating are unlearned.