Hacker News Reader

Comment by sudosteph | Hacker News Reader

I'm surprised by the author's hate towards DynamoDB. It's probably one of my favorite AWS Services. Great availability and no operational overhead. Cost was pretty minimal too each time I've used it, but you do need to spend some time architecting your data model up front, and that requires reading service docs and understanding it.

View on HN

We used DynamoDB pretty much exclusively at Tinder, cause it was the founders choice early on. Horrible horrible choice and after 4 years working on it I dont see why you would.

1. you have a limited number of global supported indexes, 5 iirc, which means your queries are very limited. If your use case ever expands beyond that you're pretty screwed. 2. You will have race conditions. Strong consistency is 2x the cost, and not supported on global indexes. 3. Data is split into 10GB partitions and all the read/write quotas are split evenly by the number of partitions. 100 reads you're paying for is actually 10 reads per partition if you have 10 partition. Hot sharding becomes a real problem.

Take your document data, stick it in a JSONB and you get the same performance way cheaper + query able/indexable columns. The only time Dynamo wins I think is it scales well globally, but you probably dont need it

IMO if you've got a use case that requires querying in so many ways that you need several indexes, then DynamoDB is probably the wrong choice. It excels at stuff like user specific histories that are well partitioned, read back in one way, and ideally can be written asynchronously by a separate writer process.

At the beginning there was only one query, it got expanded over time with new features. It wasnt well thought out, no.

If you need high scale globally distributed persistent data, uniform distribution of hash reads/writes, dont care for schema, and know your query will remain simple yeah its a fine choice.

I just wouldn't consider it outside of enterprise level

> you have a limited number of global supported indexes, 5 iirc

you can create 20 global (GSI) and 5 local (LSI) indexes per table[1], I think the number must have been lower at some point in the past, because it's not the first time I hear this complaint

[1] https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

No I just misremembered and mixed up the global and local.

That's pretty much what I came into this thread to say. The thing I'd add is, DynamoDB is pretty nice if you understand how it's meant to be used - a relatively dumb key-value store with good persistence and table-size scaling to the sky. Definitely don't attempt to use it as a SQL database.

The best way I can come up with to rack up a $75 bill for some prototype code is to vibe-code a thing that attempts to treat it like a SQL database with JOINs and GROUP BYs etc. Or similarly write code against it absent-mindedly with about as much understanding as a 2-year-old free AI tool.

Where it really shines is use-cases like I need like 1 or 2 simple relatively small tables of persistent storage and don't want to deal with a full RDBMS. Or I need 1 ridiculously huge table to be queried in a relatively simple way, and don't want to deal with fitting that data into a RDBMS.

With AI now writing queries is a joke. But you can just create a two column table: key, JSONB and call it a day and you get your easy document store + indexes, json search, relationsl goodness, and atomicity, consistency for free

Dynamo, and a lot of the other services mentioned (Lambda) have very specific use cases. Do not use happy fun key value store as your database.

I'd say "use it as your database if you know your access patterns make it suitable/well-suited for its use as your database". Even then it will probably not be your only database — if it's part of your MSA/SOA.

I would not build in DynamoDB if you suspect your access patterns will drastically change over the lifetime of the application (or if you intend to, e.g., plan to build a data warehouse or something crazy with it).

Here to say the same thing.

I built an app a few years ago and needed some sort of DB to store around 50 million records that had ~10k reads+writes per month with 1 index. It cost me something like $50 to load it up initially, and then something stupid like 10 cents/month to maintain.

"~10k reads+writes per month"

It is the same story over and over again. Your AWS bill is "low" because the actual resources you use are a tiny fraction of what a modern computer can deliver.

This is probably fine for your case, but you could run the same load on any toaster, and without a meaningfully demanding task it is hard to tell them apart.

I might be holding it wrong, but last time I tried to use DynamoDB it made absolutely no sense performance-wise to me. Postgres on my laptop was many orders of magnitude faster for fraction of price. It seemed like it maybe might make sense when you hit multiple TBs of database data and can no longer run on a single server? But then the costs would be sky-high and you probably could engineer your way around this with this kind of money.

It's hard to do apples to apples performance with postgres - it really does depend on the data model and how you interface with it, but the thing about performance for DDB is that it can be very consistent. Pricing also depends a lot on your access patterns and data structures.

For me though, it's not having to worry about DB uptime, performance, or version updates that keeps me reaching for DDB even for small hobbyist stuff. But I'm also comfortable architecting for it, probably more comfortable than I am for traditional dbs, so that's a huge part of it.

When you do a DynamoDB write it's replicating that write to 2 other datacenters before ACK (for availability + durability reasons). Your local Postgres instance doesn't need to make any network hops at all.

DynamoDB handled >100M qps during prime day, and its storage is effectively infinite. You don't have to self manage sharding, failover, CDC, etc.

disclaimer: I work for AWS (but not on DDB)

Reply on news.ycombinator.com