[Notes] Why Amazon DynamoDB isn’t for everyone

https://read.acloud.guru/why-amazon-dynamodb-isnt-for-everyone-and-how-to-decide-when-it-s-for-you-aefc52ea9476

So when you combine inexperienced devs, the lack of a clear plan for how to model a dataset in DynamoDB, and a managed database service that makes it really easy to ingest a lot of unstructured data — you can end up with a solution that spirals out of control even at a small scale.

Quick and dirty prototypes done with try and error models would be the best use case for DynamoDB. At the same time, building a real product directly on top of a working prototype is a dangerous approach and set up for failure.

A relational database will do most anything you need at small scale. It might take a little longer to set up initially than DynamoDB, but the well-established conventions of a SQL implementation can protect you from a lot of wasted time down the road.

The initial time it took can take you way further than you would expect if you head down the RD SQL way.

So if your application is using too many RCUs on a single key, you either need to over-provision all the other partitions (expensive), generate a ton of “Throughput Exceeded” errors (not ideal), or figure out how to decrease access to that key.

One takeaway here is that DynamoDB isn’t necessarily suited to datasets that have a mix of hot and cold records.

End of the date, if it is a good use case for DynamoDB, it should also be a good use case for Azure Table, which in my opinion, even much simpler and much more scalable. And Azure Table is truly performance-provision-free.

Business value trumps architectural idealism every time.

That kind of decision making can tell a mature architect from a mediocre one, especially for the line of business software development.

This is why Lynn Langit has more or less abandoned NoSQL as a solution for small and medium-size businesses.

It depends on the balance. Breaking schema changes in SQL is a huge pain. Plus if CI/CD, no-downtime deployment is a must-have, involving changes to the index, for a relatively large database, SQL will take a bigger hit. But anyway, to do all the above, even NoSQL won’t be trivial.

Leave a comment