Stuck with “NoSQL”?
While listening to the energetic and thoughtful discussion between the RIAK team and Tim Anglande I was struck by the difficulty of coming up with a better moniker than “NoSQL”. There is always a period at the beginning of a technology when it is understood in terms comparing it to the status quo–horseless carriage, wireless telegraphy, digital photography. When the technology is socialized (that is, widely understood and applied), these terms are replaced with positive terms–automobile, radio, imaging. NoSQL is still at the first stage, but I’m not sure there will ever be a clear term positively encompassing all the technologies it encompasses. Here’s why.
Here is the picture as of maybe ten years ago. The needs of almost all applications were covered effectively by row-oriented relational data stores. However, because these stores were mature, further improvements were discounted by the Law of Diminishing Returns.
Here is the picture for applications that require frequent schema changes. The need for plasticity exceeds the ability of SQL to deliver, at least at a reasonable cost. I’ve worked on a life insurance system for 12 years that has relied on the ability to make daily schema changes. We wouldn’t have been successful with any SQL + ORM technology I know but our object database (Gemstone) handles such changes gracefully for the amount of data we need to manage.
The picture also shows where document-oriented databases like MongoDB or CouchDB fit in. There are things you can do with a row-oriented relational store that you can’t do with Mongo or Couch, but the key advantage they offer is the ability to rapidly change the shape of data. If that’s what your application needs, for example in a rapidly evolving startup, then a document store is a win.
Here is where the futility of defining NoSQL as anything but a negative space becomes apparent to me. There isn’t just one dimension along which SQL stores are inadequate for some applications, there are half a dozen. Different vendors address different subsets of these criteria. There is some overlap (I tried drawing several stores into this picture but it quickly became spaghetti), but the differences between the stores is large relative to their commonality.
To name the universe of all these products, you’d have to call them something like “better than SQL in one or two ways but worse in several others that don’t matter in some circumstances”. Shorten that to a phrase that fits on a T-shirt and you get “NoSQL”. I’m afraid we’re stuck with it for a while.