Reasons for choosing NoSQL DBs can often be achieved through better design

In reading up on NoSQL, I haven't read anything about truly superior storage technologies. Instead, I just read about design trade-offs - faster writes in exchange for slower reads... faster reads as long as you don't do any joins... As far as I can tell, you can achieve the same design choices with a standard relational database or file system or a combination.

It seems you can get the same orders-of-magnitude gains just by implementing the design choices of NoSQL technologies onto plain-old RDBMSs or file systems. Indexes slowing you down? Then reduce the indexes. Writes too slow? Then write to file and index later. Joins too slow? Then set up a denormalized OLAP database. See? Same design choices lead to the same order of magnitude gains. The difference is that you're not tied to that design choice. Unlike embracing MongoDB or Cassandra, you're limited to the design choice choice chosen by those technologies.

Horizontal scalability can be achieved by design, not by technology choice. With proper design, you can shard a relational database - you just have to design it so you avoid queries across shards. DBAs have been doing this for decades. But even if you choose the best NoSQL technology to shard your data, if you regularly do queries across shards, it'll crawl. There is no substitute for design.

People are so eager to drop a half-a-century's worth of storage technology in order to jump onto the next "cool" thing. Just because your competitors are using it doesn't mean they're right, it may just mean that they've been caught up in the hype.

Have we all stopped becoming software designers and instead just become tool users? Picking a tool doesn't make you an engineer.