686

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.

Ramesh R
  • 7,009
  • 4
  • 25
  • 38
Luke101
  • 63,072
  • 85
  • 231
  • 359
  • couchdb is more that just a database: it allows the creation of server side web applications, using javascript (or other languages). It also manages you web cache (using etags) for you. I do not know about mongodb. – ctrl-alt-delor May 29 '16 at 17:41
  • I am surprised no one has mentioned the CouchDB changes_ feed. I find this to be very useful, specially when you open a keep-alive or longpoll connection. More info at http://docs.couchdb.org/en/2.1.1/api/database/changes.html – gdelfino Jan 18 '18 at 16:44

7 Answers7

551

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.

starball
  • 20,030
  • 7
  • 43
  • 238
user799188
  • 13,965
  • 5
  • 35
  • 37
  • 9
    From what I understand MongoDB is not consistent in any way: http://ivoras.sharanet.org/blog/tree/2009-11-05.a-short-time-with-mongodb.html – sheerun Aug 06 '14 at 23:26
  • 2
    Good info for the time, but this is really old... lots has changed (including REST interfaces for Mongo). – rICh Oct 12 '14 at 23:24
  • 1
    Some further comparisons and code examples here: http://www.scottlogic.com/blog/2014/08/04/mongodb-vs-couchdb.html – ColinE Nov 11 '14 at 08:36
  • 1
    MongoDB seems to have a much higher distribution, if you trust google trends for that: http://www.google.at/trends/explore#q=MongoDB%2C%20couchdb – Gerwald Dec 18 '14 at 12:12
  • 4
    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 Feb 20 '15 at 11:40
  • 2
    I'd add to the list that couchdb can have self contained web applications. As in couchdb is in fact a webserver. – Loïc Faure-Lacroix Feb 20 '15 at 11:41
  • 43
    I am surprised 332 votes for a wrong answer. MongoDB is CP by default and CouchDB is AP http://stackoverflow.com/questions/11292215/where-does-mongodb-stand-in-the-cap-theorem – adnan kamili Apr 08 '15 at 11:10
  • 1
    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. – antonio.fornie Apr 28 '15 at 20:25
  • 1
    There have been edits made by the community since the original reply which did say MongodB is CP and CouchDB is AP – user799188 Apr 29 '15 at 03:04
  • Mongo => CP, Couch => AP as per the no sql visual diagram. I am confused which one is correct. – Sambit Tripathy Oct 06 '15 at 18:48
  • @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 May 05 '16 at 16:25
  • @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. – Loïc Faure-Lacroix May 06 '16 at 09:55
  • @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. – OrangeDog May 06 '16 at 10:00
  • @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. – Loïc Faure-Lacroix May 06 '16 at 10:49
  • @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. – mljrg May 05 '18 at 01:07
  • 1
    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. – Jonathan Hall Apr 04 '19 at 08:05
251

The answers above all overcomplicate 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.

Ramesh R
  • 7,009
  • 4
  • 25
  • 38
Ewan Makepeace
  • 5,376
  • 9
  • 31
  • 31
  • 3
    "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? – Ewan Makepeace Apr 15 '16 at 16:34
  • If your code will only run on *one* server. Sorting out a highly-available system is a lot easier with multi-master replication. – OrangeDog May 05 '16 at 16:27
  • 1
    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. – Bill Stephenson Apr 02 '20 at 21:39
86

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.

Update December 2022: Since this post is still getting a lot of views, I felt important to inform people that I have recently moved to using MongoDB as my daily driver, while keeping CouchDB in my toolbelt for specialized cases where this database makes more sense (namely cases where views are not needed). There were multiple reasons for this choice, the most important ones were:

  • Performance: While precomputed indexes are a powerful asset, the main limitation of CouchDB is its QueryServer architecture. Every time a document is updated, it has to be serialized and processed by every view (even though this happens in a deferred manner, namely when the view is accessed). But more importantly, every time a view is updated (for example to add filtering logic for a new field added as part of the implementation of a new feature), ALL documents of the database must be sent to the view. This becomes a big deal when you have millions of documents in the database. You start worrying about the impact of updating your views and it becomes a distraction. Should you decide to create one database per data type to bypass this limitation, you'd then lose the ability to map/reduce across all your documents since views are scoped per database. MongoDB avoids this by segmenting documents into collections (ie. data types) so that when an index is updated only a subset of the data of the database is impacted. Moreover, MongoDB uses a binary format making these operations way more performant (while CouchDB uses JSON sent to the view server in plain text). This point may not be important if you do not design products needing to operate at large scale (hundreds of thousands of daily users or more).
  • the tooling available with MongoDB is comprehensive and mature, whether we are talking about the drivers officially supported for various programming languages, or integration with IDEs.
  • Advanced querying: A wide range of data types and advanced query capabilities are available out of the box (geo types, GridFS allowing one to store files of arbitrary size directly in the DB etc...). Having easy access to powerful query aggregation capabilities made me realize how much CouchDB had been inhibiting my productivity.
  • Seamless support for resharding: resharding is easy with MongoDB, while it is a dangerous operation involving moving files by hands with CouchDB.
  • Many other small items that improve quality of life and really add up.

I have been a big CouchDB fan but I have to admit that moving to MongoDB as a daily driver felt a lot like moving back to civilization in terms of productivity and quality of life improvement. Now I only consider CouchDB for key-value store scenarios (in which no map-reduce views are required and all that is needed is getting a document by key - CouchDB shines quite a lot for this), and advanced situations in which having per-user like databases is needed (for example to support advanced synchronization between devices).

The only drawback I see with MongoDB is that it consumes a lot of memory to the point that I cannot install it on development machines having low specs (while by comparison couchdb is launched at startup without me noticing and consumes almost no resource). However I feel this is worth it considering the time saved and the features provided.

As a long-time CouchDB user, the value I see in MongoDB is quite different from the items highlighted in the other answers promoting MongoDB so I felt it was important for me to provide this update (and also out of intellectual honestly when I remembered this post). CouchDB gave me quite a boost in productivity back in the days compared to the SQL products and ORMs I had been using, and at that time there were a lot of horror stories circulating regarding the reliability of MongoDB.

However, as of now, the few concerns I could have (and that were probably given disproportionate importance by internet folks - they essentially all boiled down to defaults whose reliability tradeoffs may surprise new users in a number of scenarios) no longer stand.

At this point, as a long-time CouchDB user in a great position to compare both products, I would recommend MongoDB to people needing a productive and scalable software development experience for their web app and advise to only pick CouchDB for specific needs.

CouchDB had momentum back in the days which probably influenced my perception, but development has stalled, no meaningful features have been introduced for a long-time, otherwise it would probably have caught up with MongoDB in terms of quality of life. I see two possible reasons for this: the way a now aborted rewrite of CouchDB has diverted resources for a long-time, and maybe early architectural decisions (such as the Query Server architecture) that may very well have restricted its future from the start. None of these aspects seem to be the priority of the core team.

I do not totally regret choosing CouchDB because it has been massively helpful and the mindset it has taught me is extremely helpful to allow me to write performant code in MongoDB (writing performant code in MongoDB is a breeze compared to the discipline one has to observe to solve business problems using CouchDB). However if I had to do it again today, I would have transitioned to MongoDB as my daily driver MUCH sooner. I'm usually quite good at picking the winning horse when technologies popup, but this time it seems I haven't played the game that well. Hope this helps.

tobiak777
  • 3,175
  • 1
  • 32
  • 44
  • 20
    Update 2016 : Since version 2.0 released in september 2016, CouchDb is supporting ad-hoc queries out-of-the-box :) – tobiak777 Oct 22 '16 at 12:45
  • 2
    `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. – Shelvacu May 14 '19 at 07:18
  • 1
    @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 Jun 02 '22 at 20:22
  • 1
    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. – tobiak777 Jun 02 '22 at 20:27
48

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
marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Somnath Muluk
  • 55,015
  • 38
  • 216
  • 226
28

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

Alexis Dufrenoy
  • 11,784
  • 12
  • 82
  • 124
24

Be aware of an issue with sparse unique indexes in MongoDB. I've hit it and it is extremely cumbersome to workaround.

The problem is this - you have a field, which is unique if present and you wish to find all the objects where the field is absent. The way sparse unique indexes are implemented in Mongo is that objects where that field is missing are not in the index at all - they cannot be retrieved by a query on that field - {$exists: false} just does not work.

The only workaround I have come up with is having a special null family of values, where an empty value is translated to a special prefix (like null:) concatenated to a uuid. This is a real headache, because one has to take care of transforming to/from the empty values when writing/quering/reading. A major nuisance.

I have never used server side javascript execution in MongoDB (it is not advised anyway) and their map/reduce has awful performance when there is just one Mongo node. Because of all these reasons I am now considering to check out CouchDB, maybe it fits more to my particular scenario.

BTW, if anyone knows the link to the respective Mongo issue describing the sparse unique index problem - please share.

mark
  • 59,016
  • 79
  • 296
  • 580
  • 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. – mark Feb 28 '13 at 15:12
  • 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). – ANeves Nov 20 '13 at 12:17
  • The point is there are real uses for this concept and MongoDB just does not do it right. – mark Nov 20 '13 at 16:01
  • 1
    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. – Snowburnt Jan 30 '14 at 15:42
  • @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}). – Colselaw Aug 30 '16 at 02:40
  • 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. – mark Aug 30 '16 at 02:55
  • 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.) – Colselaw Aug 30 '16 at 03:06
7

I'm sure you can with Mongo (more familiar with it), and pretty sure you can with couch too.

Both are documented oriented (JSON-based) so there would be no "columns" but rather fields in documents -- but they can be fully dynamic.

They both do it you may want to look at other factors on which to use: other features you care about, popularity, etc. Google insights and indeed.com job posts would be ways to look at popularity.

You could just try it I think you should be able to have mongo running in 5 minutes.

Ramesh R
  • 7,009
  • 4
  • 25
  • 38
dm.
  • 1,982
  • 12
  • 7