Weaknesses with different types of NoSQL databases

Question

Here's my question: What are the weaknesses with different types of NoSQL databases? Specifically, what're the weaknesses of key-value stores, graph data stores and document stores?

I've had an easy time finding strengths, but documents on weaknesses seem to be scarcer.

Edit: In comparison to each other, and to relational databases.

Answer 1

The biggest strength/weakness of any distributed data store comes from the CAP theorem. See http://blog.nahurst.com/visual-guide-to-nosql-systems for a quick rundown of what it means in practice for a large number of NoSQL systems that are out there.

Answer 2

If you are comparing them to relational databases, the obvious weakness is that key-value stores are not relational. Consequently, it can be more difficult to write reports using key-value stores than it is using a relational database, for which such reports and data extraction are specifically designed.

Answer 3

This is very subjective, what you think might be a weakness, someone else might think is its greatest strength.

All the NoSQL databases that are currently popular are addressing issues that existing RDBMS systems were weak at, and they are usually highly specialized at one particular problem the originator had and was trying to solve.

So, any products weaknesses is its in-ability for it to do what you need it to do in a time or space efficient manner.

Answer 4

I'll start by noting that I love NoSQL databases and I'm in the process of ditching our SQL-based databases and applications where it makes sense. This process has brought one major weakness to light -- the operational story just isn't there yet. What I mean by this is:

• NoSQL is still a fast moving target. You need to be pretty intimately familiar with it to know what changed between versions. From an operational perspective this creates a few difficulties -- sysadmins are used to reasonably documented stuff with best practices. When best practices haven't been defined it gets a bit scary for them.
• Very, very few people out there are familiar with operating them beyond the development community. This makes it a challenge when you want to hand off the product to operations and be done with it.
• The better ops types tend to be able to handle light SQL, and at least recognize it. Json or whatever your nosql speaks is a bit of a learning curve.
• Reputation is a tricky thing -- data loss is very scary to the ops types. They have come to believe that SQL databases will survive nuclear holocaust. NoSQL will be a bit of a sales job there.

Other tricky thing at times is reporting -- lots of userland tools can hook directly into sql databases, NoSQL still requires a developer to cross that bridge.