On occasion, I've railed against the NoSql saga. If data doesn't really matter, then any file datastore will do. If it does matter, then either you use an existing TPM (CICS is still around), RDBMS (TPM built in), or roll your own. Since TPMs have been around since before CICS, and there is decades of experience figuring out how to do them, a few kiddie koders with php ain't likely to get there any time soon.
But recently there's been a dawning recognition among NoSQL practitioners and those working in Big Data that the fast-iterating data they process needs to be demonstrably reliable, too. The result has been NoSQL databases adding more relational functionality to their software.
"D'oh!" quoth Homer.
It gets better:
"We think one of the reasons there are so many NoSQL databases on the market is because unless your application perfectly matches their data model, it becomes difficult to build data abstractions."
Well, of course. The NoSql approach is tied to file defs and implementation language. This is the Achille's Heel of API-centric coding. The RDBMS/SQL is client language agnostic, and so long as one sticks to reasonably standard SQL, engine agnostic as well. For those eager to port across engines, there's the likes of SwisSQL.
"A distributed data store without concurrency control is a toy and makes building things on it a lot harder."
What is left unsaid, even by Rosenthal who is, by his own admission, just a coder, is that industrial strength RDBMS (DB2, of course) have had distributed transactions for decades. Gray and Reuter devote much of chapter 16 to distributed CICS, for crying out loud. Nothing as much fun as inventing the wheel. Again. And worser (isn't that a city in Poland?).