The great NoSQL debate - what NoSQL is NOT good for

Hey, after a long pause, and after having glossed over how nice NoSQL databases are, we finally arrive to the blood and tears part. The one that generates controversy. Even passion. Which is a lot to say and gives the debate a new twist outside of the usual rational (some even are relational) database folks. That's why I'm using as a headline for each point some of the more passional statements made against NoSQL that I've come across.

Face it, you're not Google

(and the sooner you realize it, the better) This argument is really a variant of the classic "you don't need it anyway" and points to one of the touted NoSQL advantages, its extreme scalability.

And it's true that the levels of scalability provided by NoSQL are way beyond the needs of most business, except of course Facebook, Google, and perhaps a few hundred sites that top the Alexa ratings. The rest of the world is not really facing an scalability problem, really what they have is a database tuning problem.

So, investing a lot of time and resources in some technology whose main benefit is something you're not going to ever need is aking to buying a supercar capable of hitting 300 kilometers per hour. It's all very good, but you can actually do with much less top speed. Startups would make much better use of their money if they focus on attracting customers and building a solid product that can meet their current capacity demands.

Actually, capacity problems in this scale are a good problem to solve. If you're under pressure to increase your database performance at an exponential rate, it means that the business it supports is alsow growing and on its way to profitability.

(Shameless self-plug: actually, if you've just started your new business and you're having performance problems chances are that you don't need to switch to a NoSQL database, your money would be much better invested in dabase and application tuning instead)

We've seen all this before

Anyone remembers the XML hype wave? XML was to change the world and of course every single database conceived since then. XML was everywhere and lots of people were putting bright ideas on the table to take advantage of XML. Databases that did not embraced XML wholeheartedly would die a slow and agonizing death. Anyone remembers the object database hype wave? More of the same.

Hardly any of that has happened. The helicopter view of NoSQL databases is that they are some kind of distributed, fault tolerant huge hash table. This kind of ideas work well on very specific problem domains, but they lack the expresiveness of the relational operators and constructs that relational engines have. Maybe over time they will acquire some of their abilities, but no doubt that will have a cost in terms of simplicity and scalability, making them lose part of their attractive.

Better the devil you know

Relational databases have been around for something like 30 years. There are extensive bodies of knowledge and code that have been debugged to death during decades. There are lots of vendors and skilled resources available to deal with them. There are extensive bug databases covering decades-old releases. There are compatibility suites, industry benchmarks and all kinds of useful methodologies and devices to deal with them.

in contrast, NoSQL databases don't have such enormous inertia. While almost nobody switches from one relational engine to another in the middle of a project, part of the relational attractive is that you know that, should you want to switch to another relational engine, you still know that it's actually possible with a bit of work. More or less difficult, but not impossible and within the reach of mere mortals.

And should you found a problem, a bug or have one of those questions that is best answered by the wisdom of crowds, good luck. Because as enthusiast as the NoSQL is, there is little in the way of best practices, seasoned professionals or years of experience.