NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



What NoSQL is NOT good for

Wondering if these arguments are valid? Let’s take a look at each of them.

Face it, you’re not Google

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.

The argument alone is correct, but it’s a straw man. While some NoSQL solutions are known to be scalable, I’d say the main differentiator of NoSQL solutions is the different data model.

So, real question is: does your data fit the relational model or would it fit better with a document store, wide column store, graph database or even key-value store?

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.

In the current formulation, I’d say this argument is completely wrong as it is confusing the hype, marketing and PR around new companies and technologies with their technical merits (not to mention that object databases are continuing to be a valid solution for a range of problems). One thing that is easily forgot when speaking about some of the NoSQL solutions is that most of them are not coming from a lab, but rather they’ve been built by companies or organization that have tried to solve real problems.

As a side note, if the question would have referred to NoSQL projects being revolutionary or evolutionary then the debate would have been more interesting.

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.

I do agree with the fact that the ecosystem around relational databases is extremely rich and provides you with almost everything you need. But that doesn’t make a hammer be something different. If your data doesn’t fit a relational database, all the knowledge and tools around will at most alleviate a bit the pain your project will go through to make your data fit in.

As a side note, with this kind of argument, PCs would have been dismissed and we could still count on one hand the number of programming languages.

There are many situations in which NoSQL is not the best option, but the only way to decide that is to look at the problem you are trying to solve.