Lots of companies use NoSQL badly, and lots of NoSQL is implemented very badly. I can't help but think an awful lot of these engines read the bigtable whitepape

Lots of companies use NoSQL badly, and lots of NoSQL is implemented very badly. I can't help but think an awful lot of these engines read the bigtable whitepaper and completely misunderstand why it was important. MongoDB, for example, uses collection latches. Thankfully, these are per-server, so if you're using sharding you've got one per server. It is still no better at single-server performance than MySQL using table-based locks (except that you are unable to write a query that uses two tables), except that the latches and 'documents' (locks and rows) are lighter-weight. The writes in mongo are only document atomic. Why not use a latch per-document? It needn't be memory intensive; Use a bloom table to represent the latches, and a small amount of entries (a thousand or so) is plenty to allow real concurrency. Lots of companies use collections badly. I've seen a collection of user addresses. These make no sense as a collection; They're less than a kilobyte long. They should be an array in the user object. Mongo documents are meant to be an order of magnitude larger than SQL rows, and a few kilobytes here and there won't break the bank. You're better off doing a 1M read than three serialized 1k reads; The RTT is comparatively long, even at sub-milisecond latencies.