6 ms·
Yup, they are very serious about DynamoDB and it is a very good product. Wish they released more information about it, though.
by ferguess_k 22d ago
Yup, they are very serious about DynamoDB and it is a very good product. Wish they released more information about it, though.
- ihsw 22d ago[dead]
- felixgallo 22d agohttps://www.amazon.science/publications/dynamo-amazons-highly-available-key-value-store https://www.amazon.science/publications/dynamo-amazons-highl...
- sargun 22d agoThis is massively different from DynamoDB.
- ihsw 22d ago[dead]
- ferguess_k 22d agoIt is their previous one. I did read another paper about DynamoDB, but still there is not much details. For example, I want to know how to calculate the charge of incremental export. One blog says it is charged by the amount of change logs (but the official doc doesn't say so), which makes sense. But how do I estimate the amount? My hunch is: Put + Write + (1~100) * TransitWrite + Update + Delete + (1~25) * BatchWrite.
- senderista 21d agoNothing to do with DynamoDB except the name.
- riknos314 21d agoFor anyone interested in the differences between dynamo (the early internal-only KV store described in this paper) and DynamoDB (The AWS service), Marc Brooker has an excellent writeup https://brooker.co.za/blog/2025/08/15/dynamo-dynamodb-dsql.html https://brooker.co.za/blog/2025/08/15/dynamo-dynamodb-dsql.h...
- deleted 22d ago[deleted]
- qaq 22d agoMan I admire AWS marketing team for convincing people DynamoDB is a very good product. 100 items max per Transaction BatchGet 100 items, 16 MB max low write limits on same key Item size 400 KB max etc.
- nixon_why69 21d agoThe reason it's good is because, although it is bad, you never have to worry about it in terms of maintenance, admin or scale. It's like lambda for databases. For the same price, you can run a much more capable PSQL instance with way better features, but now you're on the hook for it being up 24/7.
- supriyo-biswas 21d agoThey should really call it "data-structures as a service" rather than a database, really. Programming against it always reminds me of Leetcode problems, having to define your columns in a way to suit the very specific lookup patterns that they allow for.
- Spivak 21d agoI mean this reminds me of Firebase v1 and FoundationDB I think both of which have a favorable reputation for quality in both design and implementation. I do think there's something to be said for being forced to code against what operations are actually fast in your DB. Once it works you can be reasonably confident it will also be fast rather than the typical RDBMS experience of getting an abundance of rope with which to hang yourself with. You often won't find out until it's already load bearing that your query doesn't scale.
- LPisGood 21d agoYou do have to worry about scale with lambda though. It’s not super hard to hit a rate limit where warm up times start being a real problem.
- ferguess_k 21d agoThanks, I don't really get any chance to seriously use or manage OLTP databases (mostly working with OLAP ones myself) so it is good to know about this. The 400KB limit is indeed very limiting -- I had to truncate some data because of that. I wish I could get a role to work on OLTP databases. PostgreSQL seems to be a fascinating topic so that's on my plate.
- senderista 21d agoThey have published 2 academic papers about it. What more do you want, operational details?
- ferguess_k 21d agoFor example, I would like to know how to calculate the charge of incremental export before I run one. One blog says it is charged by the amount of change logs (but the official doc doesn't say so), which makes sense. But how do I estimate the amount? My hunch is: Put + Write + (1~100) * TransitWrite + Update + Delete + (1~25) * BatchWrite.
- senderista 20d agoUnfortunately that seems like a question for AWS support. I'm not sure they'd be willing to document a formula.