Understanding DynamoDB’s scaling features in the console

DynamoDB is a powerful key-value database with virtually infinite scaling capabilities.

But like with all other powerful software, the weakest element is always human fault.

This is why good design of your database tables — such as intelligently selecting your primary keys, indexes, and solid data modeling — is paramount to performance and scalability.

I’ve written a lot about how you can use the techniques mentioned above for primary key design and data modeling — here is an article that can help you understand this.

DynamoDB has some powerful built-in solutions out of the box, that can help you scale from the get-go. When we create a table in DynamoDB, we can configure scaling capacities which will provision for our table read (RCUs) and write capacity units (WCUs).

To understand scaling techniques we must first understand what RCUs and WCUs are.

Read & Write Capacity Units

An RCU is a unit of data fetched from a table that is measured in kilobytes, where one RCU is equal to 4KBs of data. A WCU is a unit of data written to a table; one WCU is equal to 1kb of data.

In practical terms, this means that for every fetch request you make to a DynamoDB table, if the size of all items/data fetched in that request amounts to 4kbs, you will have consumed one RCU.

Conversely, when you write data, if the size of the item you write amounts to 1kb, you will have consumed one WCU.

DynamoDB’s pricing model is very different than traditional SQL and noSQL database costs, because you pay for consumed RCU and WCU per second instead of a fixed cost over time or a total amount of reads and writes like with other popular noSQL databases.

AWS adopts this “pay per use” with many of its services and this is what makes DynamoDB very cost efficient. Anytime you are not making requests to your tables, you are not paying anything.

So if you think your application needs to make at most 5 concurrent reads with an average of 4kb of data per second, you can provision 5 RCUs for your table. Same goes with WCUs for writes to your table, except it's 1kb of data.

In essence, the more RCUs you set the more concurrent reads your table can handle without throttling requests.

The same goes for WCUs, naturally. But of course the more RCUs you set the higher the cost for you, as the database owner, will be.

The most evident problem now becomes how can we make sure we can allow as many concurrent reads and writes to our tables without overpaying for when traffic goes down — how can we become elastic based on demand.

DynamoDB has a few tricks to help us with this issue which we’ll look at next.

Configuring Scaling Options

Now that we have understood how DynamoDB provisions throughput for our tables, let’s take a look in the console at how we can configure this throughput in terms of RCUs and WCUs.

In the Tables page, we can select the Create Table button and we will be brought to the Create Table screen.

In the Create Table page we can enter our table details and then scroll down to the Table Settings section below.

By default, the RCUs and WCUs are set to 5 each.

We can customize this by clicking on the option on the right Customize Settings.

On the screen above we have several options to help us with scaling our database and remaining elastic to scale based on demand as well.

In provisioned capacity mode, we can enable auto-scaling and set our minimum and maximum desired capacity units and target utilization percentage to let dynamoDB be elastic for us automatically.

If our traffic goes down DynamoDB will lower our RCUs to 1 per second, if our traffic spikes, our RCUs per second will attempt to match the traffic but with the maximum RCUs we have set.

The target utilization percentage is how you tell DynamoDB to aim to keep the consumed capacity units at or below 70% of the provisioned capacity. This also helps optimize costs.

In on-demand mode, you have no configuration to do. With this mode enabled DynamoDB will provision as many RCUs as needed no matter your scale and of course it will react elastically by reducing the RCUs when requests go down.

As a general rule of thumb, you want to use on-demand mode when you do not know your users’ data access behavior beforehand and use provisioned mode when you do know your users’ data access behavior.

Lastly, you should be aware that using on-demand will cost you more than provisioned mode.

This is normal as DynamoDB must do more work behind the scenes to scale elastically based on demand.

This is also a huge advantage of a fully managed database.

On top of the fact of being serverless, DynamoDB really is a great database for many use cases, especially those with massive scaling and performance needs.

Conclusion

In this article we started by understanding what read and write capacity units are and how they are used in DynamoDB.

We then went over configuring our table to have either provisioned capacity mode, letting us define the number of RCUs and WCUs we need, or use on-demand mode and let DynamoDB fully manage our read and write capacity.

These strategies enable our database to scale based on demand.

?? My name is Uriel Bitton and I hope you learned something in this edition of Excelling With DynamoDB.

?? You can share the article with your network to help others learn as well.

?? If you're looking for help with DynamoDB, let's have a quick chat:

https://calendly.com/urielas1/dynamodb-consultations

?? I hope to see you in the next week's edition!