Blog

Lets Stop Saying “NoSQL”

NoSQL to describe a database makes about as much sense as using

NoSQL to describe a database makes about as much sense as “NoSedan” to describe a car

I say the word “NoSQL” a lot. When I say NoSQL, I tend to talk about denormalized and hierarchical document/row-based data stores like Cassandra, Mongo, Couch, or HBase. But its a terrible way to use that term. Because there are also graph databases that feel even more normalized than traditional relational databases. Then there are non-relational data stores that have been around for a long time like MarkLogic or BerkelyDB. And where do search engines fit into this? They’re not relational, and have also existed for a long time before anyone cared to use the term “NoSQL”.

More and more I’m annoyed at myself when I use the term “NoSQL”. Because theres a voice in my head saying that every use of the term needs to probably have a footnote that says “document database” or “big table” inspired database. The set of things called “NoSQL” is far too broad to have meaning. I’d rather call something a search engine or a massively distributed hash table than a “NoSQL database”.

Another problem with the term NoSQL is the subtly implied migration path. As if its the “next” thing after SQL. As if to imply “Oh you’re using MySQL? Hey the 90s called, they want their database back”. More than one client has expressed a desire to “migrate to NoSQL” to not be “left behind”. If instead of asking “does it make sense to migrate to NoSQL?” they asked – “does it make sense to migrate to a massively distributed, very wide hash table with only PUT and GET?” They might say “err… no probably not”. Or they might say “yes! we’ve been slowly pushing our MySQL database to be exactly that, and its painful!”

The point is there is a menu of options from relational to search engines to document databases to simpler key-value stores, and I hate to sound like a consultant but it almost always “depends” on your problem. But lets try creating better verbiage around these problems. The question “Do we need NoSQL?” is rather hard to answer. The question “I have problem X, do we need NoSQL?” gets better. But even better “I have problem X, what kind of database makes sense for me?” will help you even further. As a “NoSQL” consultant, I might tell you that relational databases are awesome. Or I might point out how cool Datastax Enterprise is for analytics problems at scale. Who knows? As always “it depends”.

The use of the term “NoSQL” will be about as hard to avoid in our marketing/client communications as “Big Data” – its the very rough language we’ve landed on to talk about some general ideas to the non-technical crowd. But maybe we can bring some awareness that while the term “NoSQL” might start a conversation, it should almost always disappear after we get a little deeper into your data problem.