TLDR; Choosing the Right Mode for DynamoDB Scaling
Making sense of the multitude of scaling options available for DynamoDB can be quite confusing, but running a short checklist with a calculator can go a long way to help.
- Follow the flowchart below to decide which mode to use.
- If you have historical data of your database load (or an estimate of load pattern), create a histogram or a percentile curve of the load (aggregate on hours used) – this is the easiest way to observe how many reserved units to pre-purchase. As a rule of thumb purchase reservations for units used over 32% of the time when accounting for partial usage and 46% of the time when not accounting for partial usage.
- When in doubt, opt for static provisioning unless your top priority is avoiding being out of capacity – even at extreme costs.
- Configure scaling limits (both upper and lower) for provisioned autoscaling. You want to avoid out-of-capacity during outages and extreme costs in case of rogue overload (DDOS anyone?)
- Remember that there is no upper limit on DynamoDB on-demand billing other than the table’s scaling limit (which you may have requested raising for performance reasons). Make sure to configure billing alerts and respond quickly when they fire.
The Long Version: Configuring DynamoDB Tables
Before we dive in, it’s useful to be reminded of DynamoDB different service models and their scaling characteristics: DynamoDB tables can be configured to be either “provisioned capacity” or “on-demand”, and there’s a cooldown period of 24 hours before you can change again.