The term “NoSQL” has gone through more pivots than some startups I know. Starting off as a rallying cry of “we don’t need relational databases” it, over a period of time, became “not only SQL”. 

Fast forward a couple of years and there’s a ton of key/value stores that worked okay but still couldn’t change the hearts and minds of developers who really didn’t want to move a ton of data from a working relational store to something looking like a backward step.  Big Data arrived in the PR/Marketing handbook of “that’ll make a great story for the next couple of years”.  And NoSQL got sexy again as Apache Cassandra could scale over clusters of servers (and it came out of Facebook).

Play to your strengths, that’s the key.  All of this data storage is akin to photography, there’s a dozen ways to light a photo and they all have their strengths and weaknesses.  The key is to know how to work with each when the need arises.

To me it doesn’t matter if the data is in MySQL, Postgresql, a CSV file, raw text or in key/values in Cassandra/Mongo/CouchDB. The thing to learn is how to eek the best out of the data available to you.  If you require a large exercise in converting the data from one store to another then I think it’s already time to have a serious look at the project and justify why you’re doing it.

There aren’t many of use working at what I’d called truly “internet scale” where our data is located over many servers and the volume/velocity mean that clustered data stores are the norm. If you’re creating the same data quanitites as Facebook then you either work at Twitter or Facebook or in health care.

Mere mortals like the rest of us can get on fine with what we have.