Interesting read, but as with almost all of these pieces it starts off with a completely incorrect statement about old-school databases that turns it from good information to, essentially, propaganda.

"SQL (the language) and SQL RDBMS implementations (MySQL, PostgreSQL, Oracle, etc) have been the one-size-fits-all solution for data persistence and retrieval for decades."

This is completely untrue.

For instance some RDBMS systems are purely in-memory. Some are optimized for SSDs. Some are forced persistence, where durability is job #1.

With an RDBMS you have the option to use bounding (and expensive) transactions. Or you might not.

You have the option to normalize. Or to denormalize. Or to store all of your data in a giant table that is nothing but a varchar. Or to find some balance in between.

RDBMS systems have supported loose replication for many years -- see replication in SQL Server, with multiple masters, conflict resolution, and as much decoupling as you'd like.

You have always had the option of choosing and picking your style of ACID with the classic RDBMS.

The RDBMS solution was never a one-sized fits all solution. Some would then argue that either you use them as a fully-transaction, ACID, fully-normalized stack or you're "effectively using NoSQL", which is utter bunk that defies reason.

That particular bit of NoSQL advocacy has always derailed the conversation because it isn't factually correct and turns it into a religious argument.

Then there's the RDBMS are some rusty, approach-

"The SQL databases we’re using today were designed over a decade ago. They were written with the constraints of 1990s hardware in mind: storage is cheap, memory and cpu are expensive."

This, and the conclusions drawn out of this, are so extraordinarily wrong that I don't even know where to begin. It's yet another example of trying to twist reality show how the RDBMS has rusted, but it's completely in defiance of reality.

The weak point of the RDBMS chain has virtually always been I/O -- getting lots of IOPS has always been a problem, and it is virtually always the weak link in most database operations. IOPS to the disk matter because most database systems don't consider the job of a transaction done until the operations have been confirmed completed to the disk.

Storage has never been cheap (despite the absurd claims in this article). It has always been the most expensive part of the equation! To get a decent platform to run a moderate sized database on is almost always the most prohibitive part of the equation, with ridiculously expensive rigs from high end SAN providers.

But of course we now have SSDs. Limited IOPS have been the Achilles heal of the RDBMS, especially for those who heavily normalize (it's an option in some scenarios), but SSDs move us from 100 IOPS per disk to 15000+ IOPS. If anything, the RDBMS was designed for tomorrow's computer.

And for the record, at this very moment -- when I pulled up HN for a distraction -- I'm working on a MongoDB solution. Despite my appreciation of the product, I have a strong, very strong, dislike for misleading propaganda. The RDBMS has some serious downsides, but manufacturing a new reality to sell alternatives isn't the best approach.