When to use CouchDB over MongoDB and vice versa

Question

I am stuck between these two NoSQL databases.

In my project I will be creating a database within a database. For example, I need a solution to create dynamic tables.

So users can create tables with columns and rows. I think either MongoDB or CouchDB will be good for this, but I am not sure which one. I will also need efficient paging as well.

Solution 1

Of C, A & P (Consistency, Availability & Partition tolerance) which 2 are more important to you? Quick reference, the Visual Guide To NoSQL Systems

• MongodB : Consistency and Partition Tolerance
• CouchDB : Availability and Partition Tolerance

A blog post, Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j comparison has 'Best used' scenarios for each NoSQL database compared. Quoting the link,

• MongoDB: If you need dynamic queries. If you prefer to define indexes, not map/reduce functions. If you need good performance on a big DB. If you wanted CouchDB, but your data changes too much, filling up disks.
• CouchDB : For accumulating, occasionally changing data, on which pre-defined queries are to be run. Places where versioning is important.

A recent (Feb 2012) and more comprehensive comparison by Riyad Kalla,

• MongoDB : Master-Slave Replication ONLY
• CouchDB : Master-Master Replication

A blog post (Oct 2011) by someone who tried both, A MongoDB Guy Learns CouchDB commented on the CouchDB's paging being not as useful.

A dated (Jun 2009) benchmark by Kristina Chodorow (part of team behind MongoDB),

I'd go for MongoDB.

Hope it helps.

Solution 2

The answers above all over complicate the story.

1. If you plan to have a mobile component, or need desktop users to work offline and then sync their work to a server you need CouchDB.
2. If your code will run only on the server then go with MongoDB

That's it. Unless you need CouchDB's (awesome) ability to replicate to mobile and desktop devices, MongoDB has the performance, community and tooling advantage at present.

Solution 3

Very old question but it's on top of Google and I don't quite like the answers I see so here's my own.

There's much more to Couchdb than the ability to develop CouchApps. Most people use CouchDb in a classical 3-tiers web architecture.

In practice the deciding factor for most people will be the fact that MongoDb allows ad-hoc querying with a SQL like syntax while CouchDb doesn't (you've got to create map/reduce views which turns some people off even though creating these views is Rapid Application Development friendly - they have nothing to do with stored procedures).

To address points raised in the accepted answer : CouchDb has a great versionning system, but it doesn't mean that it is only suited (or more suited) for places where versionning is important. Also, couchdb is heavy-write friendly thanks to its append-only nature (writes operations return in no time while guaranteeing that no data will ever be lost).

One very important thing that is not mentioned by anyone is the fact that CouchDb relies on b-tree indexes. This means that whether you have 1 "row" or 20 billions, the querying time will always remain below 10ms. This is a game changer which makes CouchDb a low-latency and read-friendly database, and this really shouldn't be overlooked.

To be fair and exhaustive the advantage MongoDb has over CouchDb is tooling and marketing. They have first-class citizen tools for all major languages and platforms making the on-boarding easy and this added to their adhoc querying makes the transition from SQL even easier.

CouchDb doesn't have this level of tooling - even though there are many libraries available today - but CouchDb is exposed as an HTTP API and it is therefore quite easy to create a wrapper in your favorite language to talk with it. I personally like this approach as it avoids bloat and allows you to only take what you want (interface segregation principle).

So I'd say using one or the other is largely a matter of comfort and preference with their paradigms. CouchDb approach "just fits", for certain people, but if after learning about the database features (in the exhaustive official guide) you don't have your "hell yeah" moment, you should probably move on.

I'd discourage using CouchDb if you just want to use "the right tool for the right job". because you'll find out that you can't just use it that way and you'll end up being pissed and writing blog posts such as "Where are joins in CouchDb ?" and "Where is transaction management ?". Indeed Couchdb is - paradoxically - very transparent but at the same time requires a paradigm shift and a change in the way you approach problems to really shine (and really work).

But once you've done that it really pays off. I'd personally need very strong reasons or a major deal breaker on a project to choose another database, but so far I haven't met any.

Solution 4

Ask this questions yourself? And you will decide your DB selection.

1. Do you need master-master? Then CouchDB. Mainly CouchDB supports master-master replication which anticipates nodes being disconnected for long periods of time. MongoDB would not do well in that environment.
2. Do you need MAXIMUM R/W throughput? Then MongoDB
3. Do you need ultimate single-server durability because you are only going to have a single DB server? Then CouchDB.
4. Are you storing a MASSIVE data set that needs sharding while maintaining insane throughput? Then MongoDB.
5. Do you need strong consistency of data? Then MongoDB.
6. Do you need high availability of database? Then CouchDB.
7. Are you hoping multi databases and multi tables/ collections? Then MongoDB
8. You have a mobile app offline users and want to sync their activity data to a server? Then you need CouchDB.
9. Do you need large variety of querying engine? Then MongoDB
10. Do you need large community to be using DB? Then MongoDB

Solution 5

I summarize the answers found in that article:

http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each

MongoDB: Better querying, data storage in BSON (faster access), better data consistency, multiple collections

CouchDB: Better replication, with master to master replication and conflict resolution, data storage in JSON (human-readable, better access through REST services), querying through map-reduce.

So in conclusion, MongoDB is faster, CouchDB is safer.

Also: http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

View more solutions

Comments

[Nawar]

Indeed you should. Consider an entity describing a corporation. It must have a unique business number and may have a business name, which if present must be unique. The example is somewhat simplified, but it is not far fetched.

[ANeves]

Another example of sparse unique indexes could be a client table with a national id number field which by definition is unique - but can be unknown (perhaps the client is a foreigner).

[Nawar]

The point is there are real uses for this concept and MongoDB just does not do it right.

[Snowburnt]

Mongo's Aggregation framework (in version 2.4.8) works much nicer than their map-reduce and, in my opinion, easier to use and wrap your head around (I'm sure that's not the case if you're used to map-reduce, I just took the mongodb class and the aggregation framework was very flexible). The soon to be released 2.6.8 will return aggregation results as a cursor rather than a document, removing the memory limits previously applied to mapresult and aggregation calls.

[sheerun]

From what I understand MongoDB is not consistent in any way: ivoras.sharanet.org/blog/tree/…

[rICh]

Good info for the time, but this is really old... lots has changed (including REST interfaces for Mongo).

[ColinE]

Some further comparisons and code examples here: scottlogic.com/blog/2014/08/04/mongodb-vs-couchdb.html

[Gerwald]

MongoDB seems to have a much higher distribution, if you trust google trends for that: google.at/trends/explore#q=MongoDB%2C%20couchdb

[Loïc Faure-Lacroix]

I think it might be a bit misleading, but versioning in couchdb isn't an argument. The versioning scheme used by couchdb shouldn't be used as versioning per say. It is used to handle partitions. During a database compaction, revisions will get deleted as in really deleted. And only the rev chains should remain in the database. If you want to handle versions in couchdb it should be done just as it could be done in mongodb.

[Loïc Faure-Lacroix]

I'd add to the list that couchdb can have self contained web applications. As in couchdb is in fact a webserver.

[adnan kamili]

I am surprised 332 votes for a wrong answer. MongoDB is CP by default and CouchDB is AP stackoverflow.com/questions/11292215/…

[antonio.fornie]

CouchDB is AP or BASE (eventually consistent and highly available) while MongoDB is CP. Anyway I don't understand why answering these questions people give so much importance to CAP theorem prior to many other aspects and features. For example, limitations in querying CouchDB can be much bigger subject to bear in mind.

[user799188]

There have been edits made by the community since the original reply which did say MongodB is CP and CouchDB is AP

[Sambit Tripathy]

Mongo => CP, Couch => AP as per the no sql visual diagram. I am confused which one is correct.

[Ewan Makepeace]

"lol how little is your data?" - is that really a thing? I might choose CDB because my data is large - or I might choose it because it has better replication than the alternatives. In this case we filter datasets down to about 100Mb-200Mb per device. Is that a bad thing?

[OrangeDog]

@LoïcFaure-Lacroix as a serious CouchDB user, there's absolutely no reason not to implement your own versions using the db's versions.

[OrangeDog]

If your code will only run on one server. Sorting out a highly-available system is a lot easier with multi-master replication.

[Loïc Faure-Lacroix]

@OrangeDog there is... previous revision will get purged out of the database. Their only use is to detect document conflicts. After a compaction, all the previous revisions will get deleted and the only thing that will remain in the database is the revision tree. If you want to add versions to document, you expect them to survive a compaction and get deleted only when you choose to delete them.

[OrangeDog]

@LoïcFaure-Lacroix you are right, except having versions doesn't mean you have to care about anything other than the latest version. Even if you do there's no reason you cannot use the db's version field while also keeping a copy (or diff) of the previous versions in the latest revision.

[Loïc Faure-Lacroix]

@OrangeDog if you keep a copy in the latest revision, you're effectively rolling your own revision management. Also, keeping a copy inside the same object will make it grow overtime. If the objects is usually changed... better create a new object because each new insert will require to pull/insert all the previous revisions in a worst case scenario.

[Colselaw]

@mark I know this probably isn't very satisfying, but with a little trickery and tom-foolery (which already feels bad to MY gut), you can have indexes that satisfy both. You have your existing sparse, unique index. Then make another index that's not unique or sparse, but add another field to the index (after the field in question). Then you can use query hints to force the optimizer to pick the correct index (when I tested this, I needed to force the hint on the sparse, unique index to find exact matches/ranges, but didn't need the hint for finding {$exists: false}).

[Nawar]

My application was not a big data and it had a well defined schema. It was, actually, a very small data. What I did at the end is threw away Mongo and replaced it with PostgreSql. In my case it was the right choice from the very beginning.

[Colselaw]

Good call. My response was just what to do when all you have is a MongoDB hammer so everything looks like a MongoDB nail. The other tidbit I would add to the second index is to add the field you expect to get back from projection, so at least you get a covered query out of having to make the duplicate index. (e.g., if you're only going to get back the _id, then add _id as the second field in your duplicate index so that it doesn't have to pull any documents and can satisfy the projection from the index alone.)

[tobiak777]

Update 2016 : Since version 2.0 released in september 2016, CouchDb is supporting ad-hoc queries out-of-the-box :)

[mljrg]

@OrangeDog The versioning solution in CouchDB should have been more like Git, which stores all revisions, but with a means for the user to tell when to discard no more useful old revs. Loïc Faure-Lacroix is right.

[Flimzy]

This answer is mostly inaccurate with respect to modern CouchDB. CouchDB now has dynamic queries, almost exactly like MongoDB. Its replication model has also greatly improved.

[Flimzy]

#9 is a virtual tie between CouchDB and MongoDB as of CouchDB 2.x.

[Shelvacu]

CouchDb relies on b-tree indexes. This means that whether you have 1 "row" or 20 billions, the querying time will always remain below 10ms. Isn't this true of nearly all databases? This way this is phrased implies otherwise.

[Bill Stephenson]

I agree with this answer. #1 is why I chose to use CouchDB and I've not regretted it. It was probably easier for me than those coming from a SQL background because I never used SQL for my web apps. Using PouchDB.js on the client side of your app will make using CouchDB much easier. You can find it at pouchdb.com.

[Sergio Chumacero]

@Daniel W. You know filtered replication is a thing right?

[tobiak777]

@Shelvacu Indeed you make a point, what is special with CouchDB with this regard is that when using Map/Reduce, you can be sure that all your queries will always use pre-computed and incremental indexes (while with other databases, the query planner may choose not use any index, or the developer may have poorly written a query or made a mistake causing a query to do table scans). By contrast, with CouchDB all queries always leverage a pre-computed b-tree index with CouchDB Map/reduce, which makes them very fast.

[tobiak777]

However if you use the ad-hoc querying style introduced in CouchDB 2.0 (called Mango) the behavior is less predictable and some filtering may take place in-memory if you use certain operators in your queries. This is the reason I personally prefer to always use Map/Reduce as this gives me the guarantee that all queries will be answered using the pre-computed b-tree for top performance. The pre-computed, incremental and very predictable nature of CouchDb queries is one of its major benefits.