How DynamoDB Read and Write Capacity Units Work
Understanding how these capacity units work is essential for optimizing performance and cost.
Read and Write capacity units or RCUs and WCUs are DynamoDB’s currency.
They are used to measure the core element of your table costs.
As opposed to many other NoSQL databases, DynamoDB uses read and write throughput as the main pricing model (besides for storage costs).
Your job as a DynamoDB developer is to learn how to optimize this currency to be able to efficiently query your database while using using up as little capacity units as possible.
There are a variety of ways to optimize this currency and it all starts with understanding how these capacity units are calculated in DynamoDB.
Let’s start by understanding read capacity units and then write capacity units.
Read Capacity Units (RCUs)
DynamoDB measures read operations with read capacity units which determine how much data you can read per second.
Each RCU represents one strongly consistent read request per second for an item up to 4KB in size, or two eventually consistent reads per second.
(What is strong and eventual consistency ? Read this).
For example, a strongly consistent read of a 5KB item consumes 2 RCUs — 1 RCU for 4KB and another for the remaining 1KB).
An eventually consistent read of that same 5KB item will consume 1 RCU — since 1 RCU can support up to 8KB.
Let’s calculate RCUs for a real-world scenario.
Imagine you have an e-commerce application that reads 100 orders from your database per second. Each item is about 6KB and we use eventual consistency.
Here’s the calculation of the consumed RCUs:
What does this mean in terms of costs?
Well if we assume the 100 orders are consistent throughout every second, hour and for the duration of an entire month, then this will translate to the following costs:
So at 100 orders per second, an entire month's worth of read requests would only cost you $7 per month.
Note: this is in provisioned capacity mode, on-demand mode may likely end up costing you less, especially since the on-demand 50% price cut announced recently.
Write Capacity Units (WCUs)
DynamoDB measures write operations using WCUs, which determine how much data you can write to your database per second.
Writing one item up to 1KB in size will consume 1 WCU.
If the item is larger than 1KB, it will use up additional write capacity units.
Let’s take an example again. If your e-commerce app now makes 50 orders per second and each order item is about 2KB in size, you will be consuming 50 x 2 = 100 WCUs.
On-demand vs Provisioned Capacity
Now DynamoDB offers two different capacity modes to manage RCUs and WCUs.
On-demand mode: DynamoDB provisions RCUs/WCUs as your requests rise and fall.
Provisioned mode: you can specify the RCUs/WCUs you think you need.
Here are the differences between the two in regards to capacity units:
With on-demand, you pay per requests you make — read request units or write request units (RRUs & WRUs). So costs are based on actual read and writes, not on units you provision in advance.
With provisioned mode, you pay per read/write capacity units you pre-provision and not on actual usage. Therefore, if you don’t use up all of your capacity units, you essentially “overpaid”.
With on-demand, you don’t overpay since you have a pay-per-use pricing model.
When should you use which?
Ideally, provisioned mode is better when you have predictable and stable read/write requests on your database tables.
On-demand mode is ideal when you have fluctuating or unpredictable workloads.
Optimizing Read and Write Capacity
As I mentioned above, with DynamoDB it is essential to know how to optimize read and write capacity.
Here are some ways you can make your database more efficient and reduce costs:
Use eventual consistent reads instead of strongly consistent reads. Eventually consistent reads are the default so you have nothing to change in your requests.
You can batch reads and writes to optimize throughput. A batch write of 25 (the max batch size in DynamoDB) items will make a single API call to DynamoDB, reducing network round trips and latency; it won’t change the WCUs consumed though.
Use on-demand mode for changing user traffic patterns. It often becomes cheaper with DynamoDB’s new on-demand pricing plan.
Use caching like DAX to reduce read capacity usage.
Compress data and use shorter attribute names in more dire circumstances (can become effective at high scale).
Conclusion
DynamoDB uses two main cost-measuring units — read and write capacity units.
By understanding how these RCUs and WCUs work and by choosing the right capacity mode, you can optimize costs and latency in your database tables.
Being able to calculate capacity units can let you make better capacity-planning decisions and build more efficient DynamoDB tables.
👋 My name is Uriel Bitton and I’m committed to helping you master Serverless, Cloud Computing, and AWS.
🚀 If you want to learn how to build serverless, scalable, and resilient applications, you can also follow me on Linkedin for valuable daily posts.
Thanks for reading and see you in the next one!