As every buzzword, NoSQL generates a lot of hype and, as a consequence, a lot of nonsense is written and said about it. On this post I hope to debunk some of the myths created around it.
Myth #1: the novelty of NoSQL
Basically the main attribute of all NoSQL database systems is the fact that they are not based on the relational model. Well: in fact since this is the most popular characteristic ( in a recent post I actually showed how meaningless it is). The Codd article in which the relational model is first described is published in 1970.
Well: does it mean that before 1970 no other database system really existed? And, since they really existed, like the CODASYL navigation system for example, and it were obviously not a relational one, based on this main attribute, NoSQL actually predated the relational model. Myth debunked.
Myth #2: forget about the schema
This is probably the myth that generates more pain on the long run. The fact that many NoSQL solutions don’t force you to adopt a rigid schema on your data does not mean that you should ignore it. Actually, it’s quite the contrary, specially as time goes by and you must know why you used those attributes.
In some cases it can be even dangerous: take MongoDB for example. As a good practice, many experienced users will tell you to define the attributes of your documents with a pre allocated size to avoid the full copy of your document when it size changes. And this is just one case: you still need to know your schema to optimize your queries with indexes and so on. So, myth debunked.
Myth #3: NoSQL scalability is always superior because, well: it’s NoSQL!
High scalability is one of the main selling points of all NoSQL database systems, but if you opt for a NoSQL solution that does not guarantee that all your scalability problems are over. What really solves your problem is a great architecture: simple as that.
I’ve alreay saw cases in which the adoption of a NoSQL brought huge gains in scallability. But on these cases I wonder if the victory was not a result of using the right data structure instead of the wrong one for that particular case. By the way, I already wrote something about it on this blog when I mentioned that the NoSQL problem is actually notational.
The funny thing about this myth is that it simply forget about the inumerous other cases where relational databases achieved great scalability too.
So yes, it’s easier to scale systems based on NoSQL solutions, but the adoption of a NoSQL database is not the only reason you’ll achieve that.
Myth #4 Unfair benchmarks
How can you fairly compare two completely distint persistent paradigms like, for example, key-value, relational, document based, and so on? I see some benchmarks that announce huge gains of performance in NoSQL using completely unfair comparisons.
It’s obvious that a key-value database will be faster then a relational one when your query involves only a key. A fair benchmark whould involve only systems which belong to the same paradigm. Then we can say something with a minimum sense.
Comparisons like MySQL vs MongoDB simply does not make any sense since they are made for different uses. If you get this huge gain, there’s a high probability that you were using the wrong data structures in the first place.
Myth #5: NoSQL provides higher productivity
Only in your dreams or if you are using the wrong tool. Since we lived for years using only relational solutions in the moment you start to use a NoSQL database you will have to pay a high price for your adaption and also your team.
Very few people talk about this, but the main challenge when you choose the NoSQL way is cultural, not technical. People fear change and move from their comfort zone, even if the solution you present is better. It’s not uncommon to see teams using MongoDB, for example, as a relational solution or cursing Redis because they only can use the key as their main query.
Productivity comes with practice, not with magic.
The NoSQL movement is by far one of the best things that could happen to developers since it open our minds to alternatives for the relational systems we were used to, but we must always remember that with each gain comes a price.