4 ms·

Is dynamo affordable yet? When I did my AWS certs a few years ago they seemed to be pushing it hard for almost every data persistence use case that was non-rela

Is dynamo affordable yet? When I did my AWS certs a few years ago they seemed to be pushing it hard for almost every data persistence use case that was non-relational. In practice the throughput provisioning meant that you knew exactly what your read/write load was and that it was constant; or you had to set it to peak levels and pay a fortune. If not, Dynamo would simply reject your request and it's up to you to build retry logic back up the chain. This got a little better when autoscaling went from a workaround to an actual feature; but there's still a fair bit of ramp-up time so you still have to handle request limits. I haven't paid much attention to it since, but was wondering if these things are a non-issue nowadays?

awinder 7y ago
You can now pay a per-request rate and skip the autoscaling / wcu & rcu math. https://aws.amazon.com/dynamodb/pricing/on-demand/ https://aws.amazon.com/dynamodb/pricing/on-demand/
- ledauphin 7y ago
  last I ran the numbers this was still roughly 10x more expensive than 100% utilization of provisioned capacity. But for many use it will still end up roughly equivalent since you won't have to over-provision.
  - Dunedan 7y ago
    I'd argue that running at 100% of provisioned capacity is something that only makes sense for a very, very small subset of DynamoDB users. Actually I'd only do it if my access patterns were really predictable and if it's fine if requests get throttled. The more common use case is that you over-provision your provisioned capacity to be able to handle some spikes in the number of accesses well. While there was already DynamoDB Autoscaling, I suggest everybody using it checks out DynamoDB OnDemand, as that might (depending on the access patterns) still save a lot over DynamoDB Autoscaling and is overall way less hazzle, because you simply don't have to care about scaling the provisioned capacity at all anymore.
    - victoriadave 7y ago
      That would be assuming you don't write more than 40k ops per second. See here in AWS's document https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html https://docs.aws.amazon.com/amazondynamodb/latest/developerg...
      - mritun 7y ago
        40K is just a soft limit. You can contact support to increase the limit to any number you like. In OnDemand mode tables have practically no limits on throughput or storage (just like provisioned mode). Disclaimer: I work for DynamoDB but comment is my own.
  - victoriadave 7y ago
    7x-ish more expensive than provisioned capacity, to be exact. For test and experimentation, it makes sense. However, if you have constant traffic in production, you'd have to consider switching between auto-scaling and provisioned capacity, but I think that can only happen once every 24 hours.
alexott 7y ago
My favorite story about DynamoDB and provisioning is https://segment.com/blog/the-million-dollar-eng-problem/ https://segment.com/blog/the-million-dollar-eng-problem/

awinder 7y ago

You can now pay a per-request rate and skip the autoscaling / wcu & rcu math. https://aws.amazon.com/dynamodb/pricing/on-demand/ https://aws.amazon.com/dynamodb/pricing/on-demand/

ledauphin 7y ago
last I ran the numbers this was still roughly 10x more expensive than 100% utilization of provisioned capacity. But for many use it will still end up roughly equivalent since you won't have to over-provision.
- Dunedan 7y ago
  I'd argue that running at 100% of provisioned capacity is something that only makes sense for a very, very small subset of DynamoDB users. Actually I'd only do it if my access patterns were really predictable and if it's fine if requests get throttled. The more common use case is that you over-provision your provisioned capacity to be able to handle some spikes in the number of accesses well. While there was already DynamoDB Autoscaling, I suggest everybody using it checks out DynamoDB OnDemand, as that might (depending on the access patterns) still save a lot over DynamoDB Autoscaling and is overall way less hazzle, because you simply don't have to care about scaling the provisioned capacity at all anymore.
  - victoriadave 7y ago
    That would be assuming you don't write more than 40k ops per second. See here in AWS's document https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html https://docs.aws.amazon.com/amazondynamodb/latest/developerg...
    - mritun 7y ago
      40K is just a soft limit. You can contact support to increase the limit to any number you like. In OnDemand mode tables have practically no limits on throughput or storage (just like provisioned mode). Disclaimer: I work for DynamoDB but comment is my own.
- victoriadave 7y ago
  7x-ish more expensive than provisioned capacity, to be exact. For test and experimentation, it makes sense. However, if you have constant traffic in production, you'd have to consider switching between auto-scaling and provisioned capacity, but I think that can only happen once every 24 hours.

alexott 7y ago

My favorite story about DynamoDB and provisioning is https://segment.com/blog/the-million-dollar-eng-problem/ https://segment.com/blog/the-million-dollar-eng-problem/