tags:

views:

483

answers:

3

With the rising of non-sql database usage in high traffic website, I'm interested to use it for my project. Now I've heard several names like Voldermort, MongoDB and CouchDB. But which are among these NonSQL database that is production ready? I've seen the download pages and it seems that none of them is production ready because is not version 1.0 yet. Is there any other names other than these 3 that is recommendable to be used in production?

+2  A: 

What do you mean by production ready? As far as I know, all of them are being used on live systems.

You should make your choice based on how the features they provide fit your needs.

You can also add Tokyo Cabinet to the list as well as the mnesia database provided by the Erlang VM.

Zed
A: 

I'm tempted to answer "use SIRA_PRISE".

It's definitely non-SQL.

And its current version is 1.2, meaning that someone like you must definitely assume it's "production-ready".

But perhaps I shouldn't be answering at all.

A: 

I think you need to start out from your project requirements to see what kind of database you really need. There are many non-relational DBMS:s out there and they differ a lot in what kind of problems they are good at solving. I think the article Should you go Beyond Relational Databases? by Martin Kleppmann is a good starting point for finding out what you need. There's also a lot of stackoverflow threads on similar topics, these are my favorites:

When you have narrowed down what you actually need you can take a deeper look into the alternatives to see which DBMS are production ready for your use case. Production readiness isn't a yes/no thing: people may successfully deploy some solution that for example lacks in tool support - in another project this could be a no-go.

As for version numbers different projects have a different take on this, so you can't just compare the version numbers. I'm involved in the graph database project Neo4j and even if it has been in production use for 5+ years by now we still haven't released a version 1.0 final yet.

nawroth
I wholeheartedly agree. Just saying "I want NoSQL" is not the solution. In fact, it is pretty much the *oppposite* of what NoSQL is all about: taking a look at your requirements and then figuring out what the best representation of your data is. And, BTW, this *includes* SQL, if that indeed happens to be the best tool for the job. However, just "I want NoSQL" is not enough. There are graph DBs, hierarchical DBs, key/value DBs, document DBs, non-SQL relational DBs. You need to figure out which one of those you need, *before* you start picking specific products.
Jörg W Mittag