Comment by llama-mini
Comment by llama-mini 4 days ago
> it only works well for well defined use-cases.
Sounds to me DynamoDB works well for well defined use-cases. That to me is a plus!
Comment by llama-mini 4 days ago
> it only works well for well defined use-cases.
Sounds to me DynamoDB works well for well defined use-cases. That to me is a plus!
Exactly this.
DynamoDB is a pain in the ass if you want to do too many relational or arbitrary queries. It's not for data exploration.
It is my favourite database though (next to S3)! For cases where my queries are pretty much known upfront, and I want predictable great performance. As Marc Brooker wrote in [1], "DynamoDB’s Best Feature: Predictability".
I consistently get single digit millisecond GETs, 10-15ms PUTs, and a few more milliseconds for TransactWriteItems.
Are you able to complex joins? No. Are you able to do queries based on different hash/sort keys easily? Not without adding GSIs or a new table. The issue in the past few years was the whole craze around "single-table design". Folks took it literally as having to shove all their data in a single table, instead of understanding the reason and the cases that worked well. And with ongoing improvements of DynamoDB those cases were getting fewer and fewer over time.
But, that's what tradeoffs are about. With on-demand tables, one-shot transactions, actually serverless storage/scaling, and predictable performance you get very, very far.
1. https://brooker.co.za/blog/2022/01/19/predictability.html