MongoDB or CouchDB - fit for production? [closed]

I was wondering if anyone can tell me if MongoDB or CouchDB are ready for a production environment.

I'm now looking at these storage solutions (I'm favouring MongoDB at the moment), however these projects are quite young and so I foresee that I'm going to have to work quite hard to convince my manager that we should adopt this new technology.

What I'd like to know is:

1. Who is using MongoDB or CouchDB today in a production environment?

2. How are you using MongoDB/CouchDB?

3. What problems (if any) did you come across when you adopted this new storage mechanism (and how did you overcome them)?

4. How did you deal with any migration issues that you had to deal with?

5. Do you have any good/bad experiences with either of these solutions that you'd like to share?

Solution 1:

I'm the CTO of 10gen (developers of MongoDB) so I'm a bit biased, but I also manage a few sites that are using MongoDB in production.

businessinsider has been using mongo in production for over a year now. They are using it for everything from users and blog posts, to every image on the site.

shopwiki is using it for a few things including real time analytics and a caching layer. They are doing over 1000 writes per second to a fairly large database.

If you go to the mongodb Production Deployments page you'll see some people who are using mongo in production.

If you have any questions about the scale or scope of production deployments, post on our user list and we'll be more than happy to help.

Solution 2:

The BBC and meebo.com use CouchDB in production and so does one of my clients. Here is a list of other people using Couch: CouchDB in the wild

The major challenge is to know how to organize your documents and stop thinking in terms of relational data.

Solution 3:

SourceForge uses MongoDB. See this presentation or read here.

Solution 4:

We are running CouchDB as a replacemant for MySQL for our shops (70.0000 items/shop, a total of 4 million attributes of all items, cross connections between items).

Our goals were:

1. Easy replication from a master-db to several clients with different documents.

2. Fast pre-calculated data like "how many parts do I have with this attribute and that filter, fitting to those conditions"

facts:

1. Our shops are now running much faster than with MySQL (and mysql-database needed additionaly 1-3 days of pre-calculating (so updating was twice a month), making the data ready for product counting and filtering, CouchDB needs 5 hours, so we could update product data every night)
2. Setting up (filtered) data distribution & backups to the shop nodes is fast and easy

but also:

1. Understanding map/reduce and the limits of not having joins is quite hard
2. No operation on data like "delete where" or "update where" without external programs
3. Replication works well, unless there is a problem; then it's really hard to find out what was the reason (for beginners)
4. The installation of CouchDB without binaries (yes there are a some in the wild, but not for every OS/version) could be hard, if you are not a Linux geek. But the CouchDB Community is helpful (#couchdb), and luckily there are companies out there (cloudant, iriscouch) that offer services from free to big business.
5. CouchDB is moving forward, so there are a lot of changes (improvements) going on that might change they way you work. But basic things remain stable.

As a result: MySQL as a database for data creation and maintaining is reliable and easy to understand and handle. I think we will not change this. But I also don't want to miss the power of CouchDB views and the ease of replication setup.

Production couches sometimes caused trouble after months of work due to misconfiguration and forgotten logrotates (view building takes too long or hangs, replication stops), but never lost data, and always could be easily reset.