3 ms·

DynamoDB is monster scale but... tricky to use and difficult pricing model. The paying for writers / readers thing is strange to me and makes it difficult to sc

DynamoDB is monster scale but... tricky to use and difficult pricing model. The paying for writers / readers thing is strange to me and makes it difficult to scale up for bursts. I recommend not using this tech for most things. You need to know exactly why you want to use it and have a good reason.

maerF0x0 6y ago
> makes it difficult to scale up for bursts Can you tell me why the On Demand mode doesnt work for you?
- whalesalad 6y ago
  You need to build exponential-backoff logic into your system to handle waiting for Dynamo to warm up. It doesn't happen instantly.
  - maerF0x0 6y ago
    You need that in provisioned in case of overload, too, right?
- arpinum 6y ago
  7x the cost. I find it interesting that the DynamoDB cheer squad points out most databases only run at 10-15% utilisation and are burning money every hour. In the next breath they suggest running on demand "till it hurts" and paying AWS as if they were running at 15% utilisation.
  - abd12 6y ago
    I recommend On-Demand pricing 'until it hurts'[0], but that's because a ton of people I talk to are spending <$50/month on DynamoDB. At that point, it really doesn't make sense to spend hours of time optimizing your DynamoDB bill. If you are at the point where you are spending over thousands of dollars a month on DynamoDB, then it does make sense to review your usage, fine-tune your capacity, set up auto-scaling, buy reserved capacity, etc. But don't waste your time doing that to save $14 a month. There are better things to do. But it's really nice to have a database where you can set up pay-per-use, don't have to think about exhausting your resources, and have an option to back out into a cheaper billing mode if it does get expensive. [0] - Hat tip to Jared Short for this advice & phrase
abd12 6y ago
I'd much rather pay for reads & writes directly rather than guessing at how my CPU and RAM will translate to the reads and writes that I need. RDBMS capacity planning basically goes: 1. How much traffic will I get? 2. How much RAM & CPU will I need to handle the traffic from (1). With DynamoDB, you can skip the second question.

maerF0x0 6y ago

> makes it difficult to scale up for bursts Can you tell me why the On Demand mode doesnt work for you?

whalesalad 6y ago
You need to build exponential-backoff logic into your system to handle waiting for Dynamo to warm up. It doesn't happen instantly.
- maerF0x0 6y ago
  You need that in provisioned in case of overload, too, right?
arpinum 6y ago
7x the cost. I find it interesting that the DynamoDB cheer squad points out most databases only run at 10-15% utilisation and are burning money every hour. In the next breath they suggest running on demand "till it hurts" and paying AWS as if they were running at 15% utilisation.
- abd12 6y ago
  I recommend On-Demand pricing 'until it hurts'[0], but that's because a ton of people I talk to are spending <$50/month on DynamoDB. At that point, it really doesn't make sense to spend hours of time optimizing your DynamoDB bill. If you are at the point where you are spending over thousands of dollars a month on DynamoDB, then it does make sense to review your usage, fine-tune your capacity, set up auto-scaling, buy reserved capacity, etc. But don't waste your time doing that to save $14 a month. There are better things to do. But it's really nice to have a database where you can set up pay-per-use, don't have to think about exhausting your resources, and have an option to back out into a cheaper billing mode if it does get expensive. [0] - Hat tip to Jared Short for this advice & phrase

abd12 6y ago

I'd much rather pay for reads & writes directly rather than guessing at how my CPU and RAM will translate to the reads and writes that I need. RDBMS capacity planning basically goes: 1. How much traffic will I get? 2. How much RAM & CPU will I need to handle the traffic from (1). With DynamoDB, you can skip the second question.