The article is strangely outdated on the CouchDB side, like someone wrote it two years ago.<p>It fails to mention that CouchDB now has Mango, which is a MongoDB-compatible query language.<p>Since 2.0, CouchDB also has Dynamo-like clustering thanks to Cloudant's open sourcing of the BigCouch code.<p>I wonder if the MongoDB side of the comparison is more up-to-date, or equally stale.
No mention of Mongo "/dev/null as a service" DB's infamous issues with data loss?<p>Apparently their new replication protocol isn't as utterly broken as the old one, but my understanding is that data recovery after server crashes is still a problem.
> Mobile support: CouchDB stands out, in that it can run on an Android or iOS mobile device. In addition to being mobile, the database can also synchronize with a remote master database, allowing the data to be shared easily between mobile devices and servers.<p>Meteor actually provides exactly this for MongoDB; it has a "minimongo" package in the browser that supports Mongo's query language, running it synchronously against an in-memory copy of the collection [0]. And with Meteor, you can specify "subscriptions" declaratively that enable bidirectional synchronization while their owner components are in scope.<p>Mongo certainly has some reliability issues (see other comments here) but I've yet to find a full-stack system so painless to develop in, <i>especially</i> if you need realtime support. With things like ToroDB Stampede [1] and a general approach of "write all your code in React with Meteor dependencies factored out into containers," there's a clear migration path towards the relational-based separate-backend-frontend world when you need to go there.<p>[0] <a href="https://guide.meteor.com/collections.html" rel="nofollow">https://guide.meteor.com/collections.html</a><p>[1] <a href="https://www.torodb.com/stampede/docs/1.0.0-beta2/about/" rel="nofollow">https://www.torodb.com/stampede/docs/1.0.0-beta2/about/</a>
> Snapshots: Any changes to a document occur as a revision and appends the information to the file. This means you can grab a “snapshot” of the file and copy it to another location even while the database is running without having issues with corruption.<p>This is the main feature I sell when pushing CouchDB.<p>Use it to project events and you'll see what I mean.
I want to make an obvious point, but I know it confused me quite a bit for a while, so just in case it helps anyone else: There's CouchDB and then there's Couchbase which is similarly named but completely different.<p>I recommend anyone shopping for databases with easy master/master replication with eventual consistency and no single points of failure to consider Couchbase as well. It's not the same will have it's own set of pros and cons.
I really liked this article for this kind of thing :<p><a href="https://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis" rel="nofollow">https://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis</a>
> MongoDB is schema-free, allowing you to create documents without having to first create the structure for that document. At the same time, it still has many of the features of a relational database, including strong consistency and an expressive query language.<p>The author clearly has a different definition of "strong consistency" than most. I don't see how any claims of consistency (in a data usage, not CAP sense) can be made of a database that can't properly store a number as a number or even guarantee that it's a number at all.<p>Also, does anyone actually like the Mongo query language? It was cute when I first saw it but I pity anyone trying to do anything complicated by manually writing those JSON strings.
I don't agrre with the article saying MongoDB is better at reading.<p>From my experience MongoDB is fast, but CouchDB really shines when you have a read heavy application.<p>Also the article didn't mention Mango queries, which is a blessing (fast indexing as erlang views), but in my opinion this feature can be a lot better with stale results, for instance.
I use couch, pouch, elasticsearch and sql dbs. I never really got the "schemaless" selling point of nosql though.<p>I do see the point of storing documents rather than rows for some use cases, or dbs extra strong on searches, etc.<p>But what is the problem with an "add column" or "change datatype" operation is sql..?
I find MongoDB easier to deploy and maintain because it's easier to build and monitor. CouchDB with Erlang not so much (for our environment, it's totally alien).<p>EDIT: I made a statement about our preference, for our environment. I did not make broad claims about these DBs for other people. How am I upsetting HN?