Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com May 9 '11 at 18:58

This question came from our site for professional and enthusiast programmers.

4 Answers 4

up vote 6 down vote accepted

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.

share|improve this answer
1  
Note that this isn't really a particular disadvantage of NOSQL. CAP theorem applies equally to any distribute data store: SQL, NOSQL, relational or non-relational. –  sqlvogel May 10 '11 at 11:48
    
Great link, thanks! –  Aedilum May 10 '11 at 16:05

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.

share|improve this answer
    
So, bottom line... There are no real weaknesses across the board that are not related to the infancy of NoSQL products? –  Aedilum May 10 '11 at 16:03
    
@Aedilum: That infancy is a pretty big caveat. –  Robert Harvey May 10 '11 at 17:36
    
@Robert Harvey: exactly, infancy begats lots of issues. @Aedilum: as a genre there isn't a horrible weakness presuming you are doing things with your NoSQL database that make sense and you've got the chops to manage it including rolling your own solution in the dark of night when production is going down because there is no manual and no paid support. Make sense? –  Wyatt Barnett May 10 '11 at 17:41

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.

share|improve this answer
    
Indeed, one of the things I've learned about NoSQL is that they're all made to solve problems that RDBMS have a hard time getting at, such as massive amounts of operations in short timespans or complex relations. –  Aedilum May 10 '11 at 16:07

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.

share|improve this answer
    
Alright, what about the other two? Near as I can tell, graph databases are all about the relations, for example. –  Aedilum May 10 '11 at 16:06
1  
@Aedilum: My experience is mostly with relational databases, but I suspect that key-value stores, graph data stores and document stores all solve specific problems. Generally speaking, each is going to be strong in the problem domain for which it is specifically designed, and weaker in the other domains. –  Robert Harvey May 10 '11 at 16:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.