NoSQL Misconceptions

I wanted to clear up a couple of misconceptions about NoSQL that I've seen much too often lately (what can I say – I watch the Twitter results for 'nosql' obsessively).

Scalability/Performance #

NoSQL is just about scalability and/or performance.

This is a particularly attractive claim for the traditionalists because it allows for the hope that these alternatives could be made obsolete in the future by making your RDBMS of choice faster or more scalable.

Unfortunately (for the traditionalist), there's a lot more to NoSQL than just performance and scaling. Most importantly (for me, at least) is that NoSQL DBs often provide better substrates for modeling business domains. I've spent more than two years struggling to map just part of the comic book business onto MySQL, for instance, where something like a graph database would be a vastly better fit.

Database Types #

NoSQL is just document databases, or key-value stores, or ...

Most of the anti-NoSQL articles I've seen have addressed only document-oriented databases or key-value stores (though recently, column-oriented databases have started to show up as well). Good arguments can be made against each of those solutions for specific circumstances, but those are arguments against a specific type of storage engine. The problem with pointing to those articles as rebutting the utility of NoSQL in general is that the label is much broader than traditionalists usually understand.

"NoSQL" covers a vast set of applications, from Redis all the way up to Neo4J. Any argument that shows that, say, document-oriented databases fail in a set of situations may very well not apply to key-value stores or graph databases, and the further arguments required to make those cases are rarely (if ever) provided.

FriendFeed & MySQL #

I can do NoSQL just as well in a relational database.

Well, sure, you can (and FriendFeed did, apparently) – but you shouldn't. I could roll my own relations in MongoDB, but that doesn't make it a good idea. Different applications are good for different things; relational databases are great for relational data, but why would you want to use them for non-relational data?

Never SQL #

NoSQL is a wholesale rejection of relational databases.

Happily, this claim is becoming less common; many proponents of NoSQL have softened their rhetoric, and the traditionalists have become a little less defensive. It seems that we're moving towards a pluralistic approach to storing our data, and that's a good thing. I've suggested 'polyglot persistence' for this approach (though I didn't coin the term), but I also like Ezra Zygmuntowicz's 'LessSQL' as a label, too.