alt Hacker NewsMan 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.
Replies
Some of the largest, highest TPS, highest throughput systems in the world use DDB.
The constraints are what let this happen. Unconstraining it might make a better generalist product but part of what you're opting into with DDB is the dumb "put an item in get an item out semantics" and the other side is knowing that it will still work if that volume increases dramatically.
The 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.
Thanks, 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.
DynamoDB has basically two legitimate use-cases that I'm familiar with:
1. You're selling a system to a customer to use within their own AWS account, that you will have no access to, and it needs a transactional datastore (not just an object bucket) of some kind. The fact that it costs nothing by default (particularly valuable when the customer is trying to deploy a proof-of-concept), scales more-or-less perfectly without anybody touching it, requires zero day-to-day maintenance by you or the customer, and all it will ever ask is that you throw money at it, is very, very much a feature. One example I'm familiar with in the wild is Teleport: https://goteleport.com/docs/reference/deployment/backends/#d...
2. You have a huge OLTP workload that fits Dynamo's KV patterns (e.g. Amazon.com shopping carts, which is what it was originally built for). You don't care how much DynamoDB costs (in either dollars or engineering limitations) because any alternative would melt your face off if you even tried.
Most of the pain that comes from Dynamo is people who try to use it as a primary datastore in place of a relational database just to get the serverless pricing model. It's not worth giving up the flexibility on greenfield systems. It does become worth it to give up the flexibility when your system is mature and you don't have genuine flexibility anymore anyway.