
Comparing Mongo DB and Couch DB - rgbrgb
http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB
======
mark242
I'm a little biased, being a pretty heavy CouchDB user, but it seems like
Mongo is claiming that their auto-sharding is the defining reason to use
Mongo. The forthcoming release of Couchbase 2.0 is going to have the same type
of functionality, with buckets distributed across the cluster rather than
required replication of the full dataset. Couchbase 3.0 should (if I remember
correctly) have the functionality for both the key/value store and for view
results.

~~~
rnewson
And BigCouch has sharding too (edited to add: for data _and_ views)

------
shiflett
Here are two relevant posts from a startup that migrated from CouchDB to
MongoDB:

<http://seancoates.com/blogs/gimme-bar-no-longer-on-couchdb>

<http://seancoates.com/blogs/gimme-bar-on-mongodb>

~~~
js4all
I don't see how these posts are relevant for a general purpose comparison. It
is one use case which doesn't fit CouchDB. Such articles give users a wrong
impression. Fact is that MongoDB doesn't fit this use case either. Good
solutions handle the following graph separate from the main implementation
using specialized graph databases.

------
rgbrgb
Basically I think this is pointing to mongo for replacing traditional website
databases and couch for only special cases. Do you guys think this is fair? I
haven't spent too much time with either but I'm a little bit suspicious
because this is from mongodb.

Anybody know of any other direct comparisons between these?

~~~
rnewson
For my part (and I'm biased) a database that doesn't consider durability
paramount shouldn't be considered a database at all.

~~~
rdtsc
It seemed a bit dishonest seeing benchmarks that showed how MongoDB beats
CouchDB in write-performance tests when there was no acknowledgement of write
requests comming back to the client.

Not saying that MongoDB wouldn't be faster with full commits turn on, it is
just that their design decision to pick that as the default and calling their
product a 'database' seemed very strange at best, and dishonest at worst.

~~~
rit
For the record: we (MongoDB) have a policy of not posting official Benchmarks.
Could you clarify what benchmarks you are referring to that were posted and
"dishonest"?

The only benchmarks we have ever done have been for internal testing
comparisons between different versions.

The "Benchmarks" page on our site clarifies this policy:
<http://www.mongodb.org/display/DOCS/Benchmarks>

Previously there were several third party benchmarks on this page, which we
recently took down to stand firmer on our benchmark policy. In the interest of
full disclosure however, you may examine the page history to verify that we
have always clarified these as unaffiliated third party sourced.

------
ConstantineXVI
I'm new to both (and noSQL in general), first heard about CouchDB a week or
two ago. Would Couch be a good fit for building a logging system, or is there
something else I should look into?

~~~
mark242
Absolutely it would be great for logging. Assuming that you don't need
atomicity for your logs (eg, I want to see that log line reflect in my reports
_right_ _now_) Couch is a perfect way to dump a huge amount of data really
quickly. For reporting, the map/reduce system of Couch is a great fit. There's
an initial learning curve -- as with anything, really -- but you'll find that
Couch would be a great way to get logged data (which can be pretty
unstructured) and report on it easily and quickly.

~~~
buster
no, it wouldn't. It would be a horrible fit, imo. You don't need versioning
info for logging, and the extra compacting of the database is another aspect,
since with logging heavy applications you will write all the time...

I love CouchDB but i definitely wouldn't use it for logging.

~~~
mark242
You don't need to worry about the versioning for a document that you never
update. You can just blast the logfiles into the database and not worry about
conflicts. Similarly, database compaction is really the biggest concern when
you're updating documents, not just dumping new ones into the database. I
would expect a very linear growth for a logging app.

~~~
tilgovi
The problem doesn't come with the inserts, it comes with the deletes, where
CouchDB will keep some metadata and stubs around to support its replication
use cases. In a pure logging setup this is perhaps less than ideal.

------
js4all
I am a fan of both and decide from case to case which one to use. Both are
under heavy development. I am often surprised about new features when checking
the newest versions.

------
superjared
\--dur

