NoSQL hard truth No. 2: Tricky transactions
Let's say you're OK to live without JOINing tables because you want the speed. It's an acceptable trade-off, and sometimes SQL DBAs denormalize tables for just this reason.
The trouble is that NoSQL makes it hard to keep the various entries consistent. There are often no transactions to make sure that changes to multiple tables are made together. For that, you're on your own, and a crash could ensure that tables turn inconsistent.
The earliest NoSQL implementations thumbed their nose at these transactions. They would offer data listings that were consistent, except when they weren't. In other words, they went after the lowest-value data where errors wouldn't make any material difference.
Now some NoSQL implementations offer something approaching a transaction. Oracle's NoSQL product, for instance, offers transactional control over data written to one node and lets you choose a flexible amount of consistency across multiple nodes. If you want perfect consistency, you have to wait for each write to reach all nodes. Several other NoSQL data stores are experimenting with adding more structure and protection like this.
NoSQL hard truth No. 3: Databases can be smart
Many NoSQL programmers like to brag about how their lightweight code and simple mechanism work extremely quickly. They're usually right when the tasks are as simple as the insides of NoSQL, but that changes when the problems get harder.
Consider the old challenge of a JOIN. Once NoSQL programmers start generating their own JOIN commands in their own logic, they start to try to do this efficiently. SQL developers have spent decades developing sophisticated engines to handle JOIN commands as efficiently as possible. One SQL developer told me he was trying to synchronize his code with the spinning hard disk so that he would request data only when the head was just above the right spot. This may seem extreme, but SQL developers have been working on similar hacks for decades.
There's no doubt that programmers spend days pulling out their hair trying to structure their SQL queries to take advantage of all of this latent intelligence. It may not be simple to tap, but when the programmer figures it out, the databases can really sing.
A sophisticated query language like SQL always has the potential to outshine an unsophisticated query language like those found in NoSQL. It may not matter with simple results, but when the action becomes complex, the SQL is being executed on the machine right next to the data. It has little overhead fetching the data and doing the work. A NoSQL server usually has to ship the data to where it's going.
NoSQL hard truth No. 4: Too many access models
In theory, SQL is supposed to be a standard language. If you use SQL for one database, you should be able to run the same query in another compliant version. This claim may work with a few simple queries, but every DBA knows that it can take years to learn the idiosyncrasies of SQL for different versions of the same database. Keywords are redefined, and queries that worked on one version won't work with another.