Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?

We are looking in to using Node.js/Redis/Socket.io to track changes to useful profile data across all of our intranet applications in real-time. No change to the current ACID setup; just hooks at the client-end. No need to persist; speed and efficiency is top priority. No extra hardware; just an extra load on our content servers.

And though we are probably in the minority we are Enterprise nonetheless.

Please don't use double negatives... shouldn't this read "Why Enterprises are Interested in SQL". (And it's a statement not a question).

Because NoSQL systems are a tool, enterprises have invested heavily in workforces and capital that are centered around SQL. It's relatively easy as an enterprise dev to get a SQL database that is going to be backed up and restored by their admins. It's ok to lose the odd 'Like' it's not ok to lose the odd deposit.

Since enterprise businesses are generally not built on a freemium/advertising model, they have the resources to buy systems that are accurate first, and then furnish hardware to provide the speed.

Another problem with NoSQL is that while the core database functionality is there, the rest of the tool chain is missing. Show me a NoSQL database that has tools on par with SQL Server management server, or has tools that integrate well with Visual Studio.

Simply put, the use-case for NoSQL is not what enterprises need. SQL fits the use case far more than NoSQL. Keep in mind that a lot of large enterprise applications still run on mainframes. If you actually think about it, most mainframe applications are NoSQL because they are still using datastores so ancient and basic that they are essentially NoSQL.

Trivial example of what people need to know in enterprises:

“Tell me whether pet rocks are selling better than Barbie dolls in the south?”

What people really need to know:

I already know from existing reporting that 984 orders (18% of our backlog) are already past due. For those 984 orders:

  - How many are for one item and how many are for multiples?
  - Do we own what we owe those customers?
  - If we do own it, is it in the proper warehouse?
  - If it is in the proper warehouse, can we find it?
  - If we can find it, is it undamaged and certified?
  - If it's shippable, do we have enough labor to ship it?
  - If it isn't certified, how soon can QA certify it?
  - If it isn't in the right warehouse, can we move it?
  - If we don't own any, where can we get some?
  - Which vendors have it on the shelf?
  - Which vendors do we have blanket purchase orders with?
  - Which vendors do we have contracts with?
  - Which orders can be split to satisfy a partial?
  - Which orders are for customers already on credit hold?
  - Which customers are threatening not to renew with us?
  
  and (ironically) the most asked question of all:
  
  - Which orders must be shipped to hit our quarterly numbers?

I can go on and on; this is just off the top of my head. We like to pick on enterprises, but this is the shit that really happens all the time. So whenever you get gas in your car, bread on your table, new shoes at the mall, steamed milk in your latte, etc., etc., etc., rest assured that someone, somewhere has asked these questions. Questions that were probably answered using some form of RDBMS, SQL, ACID technology (with really good application software on top of it).