NoSQL, Hype, and Lousy Musicians

Fine, I confess: that title is link-bait. I could have more accurately used a phrase like “Some Notes to Managers about NoSQL,” or maybe I should have called it something along the lines of “A Rant About Clueless Members of the NoSQL Fan Club.” For the record, I don’t have anything against NoSQL. By the same token, I am a relational database management system (RDBMS) guy—as a SQL Server Consultant, SQL Server has helped me pay the mortgage for over a decade—so it’s also not like I’m entirely free from bias or the epitome of neutrality either. But, if I hear another developer go off about how something they built isn’t fast because SQL Server is the problem, I think I’m going to snap.

NoSQL isn’t a Unicorn

I have no doubt that some NoSQL ‘databases’ are the right fit—for a number of SPECIALIZED projects. But treating NoSQL as if it is the de-facto, one-stop, no-problems-ever, solution to all of the worlds’ persistence problems has to stop. In other words, if you’ve looked into data storage options, evaluated the pros and cons of different offerings, compared them to the needs of your project, and come to a clear and enlightened conclusion that NoSQL is right for you (given its pros and cons), then you and I have nothing to argue about. In fact, you’re done reading. Have a nice day.

On the other hand, what I can’t stand is the whining and belly-aching I hear from developers and managers who report something along the lines of: “We tried once. It was horrible. It wouldn’t scale.” Sorry, but that kind of logic just kills me. In fact, it reminds me of a tweet I saw a while back that said: “It’s not the JS that’s the problem, it’s the morons.”

Granted, that may sound a bit harsh. But ponder this: figuring out JavaScript isn’t or shouldn’t be hard for professional developers. Nor, frankly, should it be hard for developers to figure out unit testing, design patterns, CSS, source control, or how to interact with continuous integration. Yet, somehow, while gobs of developers can keep pace with all of those concerns (as well as whatever the latest and greatest JavaScript framework released in the last 48 hours), many of them seem to fall apart and complain that writing SQL is "too hard" or "too tedious" even when talking about basic queries. Even worse is how many of these same developers (many of whom have tackled multi-threaded coding or other seriously difficult tasks in other aspects of development) react when faced with the idea that their code might be the catalyst for the problems with locking and blocking start to arise or when scalability is hampered.

Honestly, if you’re a manager and your developers tell you that scalability problems are solely the fault of a relational database engine, then it’s time to throw your developers out on their butts. To say it differently, I don’t have any issues with intelligently deciding upon the strengths of a NoSQL solution when the trade-offs are properly understood. But, as the saying goes: “It’s a lousy musician who blames their instrument,” and I swear that there’s a whole tassel of folks within the NoSQL fan-club who are, well, lousy musicians because they’re too eager to find a scapegoat for their own failings or too willing to buy into the hype around NoSQL—without adequately evaluating some of the trade-offs that they’ll eventually come face-to-face with.

Conclusion

Again, if you’ve done the necessary due diligence and thoroughly evaluated your options and want to use NoSQL, then have fun with it—there’s nothing inherently wrong with it (well, other than the fact that most types of NoSQL are patently NOT suited for some types of applications—especially those involving any kind of financial transaction or scenario where ACID is required). Otherwise, stop telling me that SQL is ‘too hard’. It makes me cranky, and I’m confident that when you say this, the problem is actually you.