one of the mongodb people wrote up a couch-vs-mongo page I found helpful.
from http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB:
Comparing Mongo DB and Couch
DB<http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB>
Added by Dwight Merriman <http://www.mongodb.org/display/~dwight>, last
edited by Dwight Merriman <http://www.mongodb.org/display/~dwight> on Mar
30, 2009 (view
change<http://www.mongodb.org/pages/diffpages.action?pageId=590739&originalId=590768>
)
We are getting a lot of questions "how are mongo db and couch different?"
It's a good question: both are documented oriented databases with schemaless
JSON-style object data storage. Both products have their place -- we are
big believers that databases are specializing and "one size fits all" no
longer applies.
We are not Couch DB gurus so please let us know in the
forums<http://groups.google.com/group/mongodb-user/browse_thread/thread/757d7f1e5f1765e8>
if
we have something wrong.
MVCC
One big difference is that Couch is
MVCC<http://en.wikipedia.org/wiki/Multiversion_concurrency_control>
based, and Mongo db is more of a traditional update-in-place store. MVCC is
very good for certain classes of problems: problems which need intense
versioning; problems with offline databases that resync later; problems
where you want a large amount of master-master replication happening. Along
with MVCC comes some work too: first, the database must be compacted
periodically, if there are many updates. Second, when conflicts occur on
transactions, they must be handled by the programmer manually (unless the db
also does conventional locking).
Mongo DB updates an object in-place when possible. Problems require high
update rates of objects are a great fit; compaction is not really necessary.
Mongo's replication works great but without the MVCC model, it is more
oriented towards master/slave and auto failover configurations than to
complex master-master setups.
Horizontal Scalability
One fundamental difference is that a number of Couch users use replication
as a way to scale. With Mongo, we tend to think of replication as a way to
gain reliability/failover rather than scalability. Mongo uses (auto)
sharding as our path to scalabity (the first sharding release is in April).
In this sense Mongo DB is more like Google BigTable. (We hear that Couch
might one day add partitioning too.)
Query Expression
Couch uses a clever index building scheme to generate indexes which support
particular queries. There is an elegance to the approach, although one must
predeclare these structures for each query one wants to execute.
Mongo's approach is more traditional: like say, MySQL, we can do queries
where an index does not exist, or where an index is helpful but only
partially so. Mongo includes a query optimizer which makes these
determinations. We find this is very nice for inspecting the data
administratively. And when an index corresponds perfectly to the query, the
Couch and Mongo approaches are then conceptually similar.
Couch's index building method, using Javascript functions, does provide an
extra layer of flexibility in how one can create keys.
Performance, ACID, REST
Philosophically, Mongo is very oriented toward performance, at the expense
of features that would impede performance. We see Mongo DB being useful for
many problems where databases have not been used in the past because
databases are too "heavy".
To ensure high speed, Mongo forgoes full ACID compliance -- in some ways it
is similar to the MySQL MyISAM storage engine. Couch has full ACID
compliance.
Couch uses REST as its interface to the database. This is very nice but is
not as fast as native drivers. With its focus on performance, Mongo DB
relies on language-specific database drivers for access to the database. A
REST API could be added in the future, however -- that would be a great open
source project -- one could for example build one as an Apache module using
the existing Mongo C++ driver.
Use Cases
It may be helpful to look at some particular problems and consider how we
could solve them.
- if we were building Lotus Notes, we would use Couch as the MVCC model
fits perfectly. Any problem where data is offline for hours then back
online would fit this.
- if we need several eventually consistent master-master replica
databases, geographically distributed, we would use Couch.
- if we had very high performance requirements, and less concern about
ACID compliance, we would use Mongo. For example, web site user profile
object storage and caching of data from other sources. Any problem with
"high volume, low value" data.
- if we were building a system with very critical transactions, such as
financial transactions, we would not use Mongo for those transactions --
although we might in hybrid for other data elements of the system. Although
for something like this we would likely choose a traditional RDBMS.
- for a problem with very high update rates, we would use Mongo as it is
good at that. For example, updating real time analytics counters for a web
sites (pages views, visits, etc.)