So, I heard that Amazon developed Dynamo because they realized that most of their table lookups were either: * looking up an item by a key * selecting a range

So, I heard that Amazon developed Dynamo because they realized that most of their table lookups were either: * looking up an item by a key * selecting a range of items I would never choose a key-value DB for "scalability" reasons. It's very unlikely that I will be hitting the kind of scale where it would actually make a difference. Where I have found it useful in my particular line of work is in a fairly narrow context: working in a microservice architecture where you create a single service between your system and a 3rd party system, and it's database is essentially a mapping of your own system's IDs to the ID's of the 3rd party. Honestly, that plus one or two secondary indexes is all I've really needed. I've done that for 3 different integrations over the course of 2 years now, and it's worked out quite well so far. The fact that we have a strict policy of not sharing db access also means that I'm not to worried about other services trying to query the data in weird ways. There are of course more fancy patterns for structuring your data in a key-value store, but at that point the main benefit of kv stores starts to diminish once you go down that path.