When I saw the DynamoDB pricing, I assumed the setup was something along the lines of "N=3, writes go to all replicas and wait for 2 responses, consistent reads go to 2 replicas, inconsistent reads go to 1 replica". Given that DynamoDB is using SSDs, I don't see why they would need to broadcast read requests to all replicas -- that's only useful if you have high variability in your read latency.<p>Someone who wanted an interesting research project might be able to pull back the covers on DynamoDB a bit by issuing a large number of requests, very carefully measuring the response latency curves for consistent and inconsistent reads, and looking at what model fits them best.
This is just the tip of the iceberg with DynamoDB's pricing issues. Based on my understanding of how their pricing works, here are two more major issues:<p>-You have to provision throughput for each table individually, so you basically have to pay for the maximum throughput you expect for every single table all the time (you can only reduce your throughput once per day as far as I understand). This means that adding a new table can be pretty expensive (even if your total throughput isn't increasing at all).<p>-Each unit of throughput gives you one 1kb write/read per second. If you exceed your throughput for a second, the call fails. This means that if you want to support the ability to write 50kb (like a "notes" field or something), you need to constantly pay for 50 write units even if you won't ever realistically use that much. And you have to do that for <i>every single table</i><p>As the OP points out, it's all about FUD. I'm so terrified of exceeding my throughput allotment that I'm forced to pay for an order of magnitude more resources than I will actually use. This seems to go against everything AWS is about.
This post brings up this interesting divide on how you price any of these services. In particular, with software (and movies, and whatever), we know that the marginal cost of producing another copy is low if not zero, and hence in some sense intellectual property can be priced arbitrarily by creators, since there aren't nice curves to determine pricing. This is often the same argument for why IP protection is reasonable.<p>At the same time, clearly this is not the case for something like EC2, where the marginal cost for another machine isn't necessarily 0, but it is true for Dynamo in some sense. Are we in a world where one can't choose to mix the model?
To be fair, they're not explicitly charging twice as much for consistent reads. You get consistent reads until you exceed your provisioned read amount, which unfortunately is measured in these odd units of "read capacity"). It's not clear (to me, anyway) if the 2x number represents something accurate about resource usage or if it's just a provisioning guideline.<p>That said, what provisioned capacity means in DynamoDB is pretty opaque. Great point about the utility of latency information for developers.