Hacker News Reader

Quite a few of the teams that were early adopters of AWS DynamoDB were not prepared for the pricing nuances that had to be taken into consideration when building their solutions.

View on HN

I remember trying Dynamodb around 2015/2016: You had to specify your expected read and write throughout and you would be billed for that. At that time we had a pretty spikey traffic use case which made using dynamodb efficiently impossible

I had a similar experience, but ultimately wrote a service to monitor our workloads and request increased provisioning during spikes. You could reduce your provisioning like 10 times a day, but after that you could only increase it and would be stuck with the higher rate for a time.

And then on-demand provisioning was released and it was cheap enough to be worth simplifying our workflows.

I was one of these. However I now understand that the pricing nuances reflected a reality that I appreciate. We used DDB in a way that was not the best fit and the cost was a reflection of this.

Reply on news.ycombinator.com