Over a million developers have joined DZone.

Cost Savings With DynamoDB On-Demand: Lessons Learned

DZone 's Guide to

Cost Savings With DynamoDB On-Demand: Lessons Learned

If you're thinking of switching to using on-demand DynamoDB, you'll want to read this.

· Database Zone ·
Free Resource

One of my favorite features that was announced during re:Invent 2018 was DynamoDB On-Demand. With DynamoDB On-Demand, we can use DynamoDB without provisioning capacity. Instead, we pay per request. Sounds amazing, huh? I was excited and re-configured all DynamoDB tables of our SaaS product marbot: cloud-native alerting for CloudWatch via Slack. The result is stunning but misleading.

I shared my excitement on Twitter, and today, I add what we learned in the following weeks.

Behind the Marketing Term

What does DynamoDB On-Demand mean? When compared with the provisioned DynamoDB model, on-demand is:

  • A table that scales the read and write throughput automatically.
  • A new cost model where you pay per request.

Scaling Takes Time

DynamoDB On-Demand does not scale instantaneously. Instead, DynamoDB On-Demand provisions capacity to handle two times the past peak traffic. As a result, if your load doubles faster than within 30 minutes, DynamoDB still throttles your requests.


There are many cases where on-demand is significantly more expensive compared to provisioned with Auto Scaling. My rule of thumb: The spikier your workload, the higher the savings with on-demand. The reason why we saw such significant savings with marbot is our workload that goes down to almost zero requests/second for half of the day in production and is mostly zero for 24/7 in our test environment. My suggestion is to switch to on-demand for one day and compare your costs with the day before.

cloud ,databases ,dynamodb ,on demand ,cost ,lessons learned

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}