MongoDB or CouchDB - fit for production?

Viewed 131599

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?

19 Answers

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.

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.

I am using CouchDB in production. Currently it stores all those 'optional' fields that weren't in the original DB schema. And right now I am thinking about moving all data to CouchDB.

It's quite a risky step, I admit. Firstly, because it's not v1.0 yet. And secondly, because it is drivespace-hungry. By my calculations, CouchDB file (with indexes) is ~30 times larger than MySQL database with the same rows. But I am pretty sure it will work out just fine.

We use couchdb in production and have since just before the project went under the Apache umbrella.

We use it to store everything that we might otherwise use a dbms, plus all sorts of unstructured data. Personally, I really like how you can just throw all sorts of data into it and use the views to cull what you don't need depending on the situation.

The hardest part was moving away from the dbms mindset. We wrote our own migration utils when the storage format changed just to be safe, so that wasn't really a problem.

We haven't had any negative experiences yet, but then again we haven't had the setup under any kind of huge load. I think things would work pretty well since we have two slave type servers that replicate from a single master server that gets all of the writes. I'm pretty sure that we don't have to do it that way for replication to work correctly, but it's how we set it up in the beginning and it stuck.

We use CouchDB to store mobile inbound and outbound messages and to report on this traffic via some custom views that I wrote. The front-end is written in Python. We did not have any real technical issues, and it has been running since the end of December. The only hurdle I encountered was initially thinking in terms of MapReduce, but once I learned how to do that, everything else went smoothly.

We are using mongodb in production for

www.beachfront.io - close to 5k write request per sec www.beachfrontbuilder.com - 500 read/write request per sec, maintain 10m users data & olap.

The only challenge faced around archiving of data, we overcome by implementing our custom component.

Related