- Excelling With DynamoDB
- Posts
- Slash Your DynamoDB Costs With Write Sharding
Slash Your DynamoDB Costs With Write Sharding
Save money on your DynamoDB bill with this sharding technique
If you’re using DynamoDB to handle high traffic write operations, chances are you’re paying more than you need to.
One of the most typical (and overlooked) issues with DynamoDB is hot partitions. And the most immediate solution is almost always write sharding.
When done right, write sharding can dramatically reduce your DynamoDB bill and increase your throughput efficiency.
Let’s break it down below.
The Problem: Overloaded Partitions
In DynamoDB, data is distributed across partitions based on the partition key. But what if your workload keeps writing to the same key, like “user#101" or “device#xyz” ?
That key maps to the same physical partition under DynamoDB’s hood, and it quickly becomes overwhelmed.
You start getting throttled, reduced write performance, and worst of all, you’re forced to provision more capacity just to support that single partition’s load.
Even in on-demand mode, this bottleneck results in autoscaling delays and inconsistent performance.
The Solution: Write Sharding
Write sharding solves this by splitting writes across multiple partitions, even for the same user or entity.
Instead of writing to the same (overwhelmed) partition “user#101”, you write to a suffixed partition like “user#101#shard-5”.
For example:
pk: `user#${userId}#shard${randomInt(1, 5)}`
So instead of writing everything to user#101, you’re writing across:
user#101#shard-1
user#101#shard-2
…
user#101#shard-5
DynamoDB distributes those across different partitions, letting you write 5x more data in parallel without increasing your provisioned throughput.
What About Reads?
Read operations need to adjust. If you want to fetch all events for a user, you now need to query all shard keys in parallel.
This can be done by a simple Promise.all() or even better a BatchGetItem to aggregate the results.
This adds a layer of complexity, but the cost savings and performance gain make it well worth it — especially for use cases like:
Analytics
Logs and metrics
Time-series data
High-traffic APIs with write-heavy operations
Choosing Your Shard Count
Start with a small number of shards (~5 or 10).
Monitor write throttling and adjust if needed. Keep the number predictable so it’s easy to reconstruct and query.
Example:
const shardCount = 10
const shardId = Math.floor(Math.random() * shardCount)
const pk = `user#${userId}#shard${shardId}`
Avoid using fully random strings (like UUIDs) for shard IDs unless you really need unpredictable distribution.
The cost savings of sharding
So how much does write sharding save you in DynamoDB bills?
Let’s say your app has a table where each user writes 50 events per second.
Without sharding, those writes all target the same partition. You end up throttled and paying for 5x more capacity than needed.
With sharding, those writes are spread out evenly.
Each partition handles a fraction of the load.
You get less throttling, better scaling, and lower costs.
Conclusion
Write sharding is often a critical strategy to implement for high-write workloads in DynamoDB.
By spreading your load across multiple keys, you can support real scalability of DynamoDB’s architecture, avoiding throttling and overpaying for underperforming throughput.
Even though it requires a shift in how you think about key design, it does pays off, quite literally.
👋 My name is Uriel Bitton and I hope you learned something in this edition of Excelling With DynamoDB.
📅 If you're looking for help with DynamoDB, let's have a quick chat.
🙌 I hope to see you in next week's edition!