[andoando]

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

[rowanseymour]

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.

[andoando]

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

[mastazi]

> 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...

[andoando]

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