MongoDB is faster than CouchDB. MongoDB provides faster read speeds. It follows the Map/Reduce query method. It follows Map/Reduce creating a collection and object-based query language.
Yes it is free to use.
MongoDB provides faster read speeds. CouchDB can be run on Apple iOS and Android devices, offering support for mobile devices. The database can grow with CouchDB; MongoDB is better suited for rapid growth when the structure is not clearly defined from the beginning.
MongoDB would not be well suited for applications that need: Multi-Object Transactions: MongoDB only supports ACID transactions for a single document. SQL: SQL is well-known and a lot of people know how to write very complex queries to do lots of things.
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.
SourceForge uses MongoDB. See this presentation or read here.
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:
Easy replication from a master-db to several clients with different documents.
Fast pre-calculated data like "how many parts do I have with this attribute and that filter, fitting to those conditions"
facts:
but also:
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.
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.
CouchDB 0.11 (released at the end of March) is a feature-freeze release for 1.0. This means we'll be maintaining compatibility with the current API for 1.0, so now is a good time to take another look at CouchDB if you haven't in a while.
The CouchDB 0.11 source code release is available here. There are binary installers and other goodies linked here.
I don't know anything about MongoDB, but from the CouchDB FAQ:
Is CouchDB Ready for Production?
Yes, see InTheWild for a partial list of projects using CouchDB. Another good overview is CouchDB Case Studies
Also, some links:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With