It's not specifically a response to this article - But you can read 10gen's view on durability here: http://blog.mongodb.org/post/381927266/what-about-durability
> To start, there are some very practical reasons why we think single server durability is overvalued.
Most people should just stop reading at that line.
> If you have durability through a transaction log, then you have to replay it to come back up.
That shows a serious misunderstanding how append-only can work. In CouchDB's case there is no need to replay the whole file just find last consistent piece of data at the end. So seek close to end & find last consistent header.
> If you have a master and slave in the same data center and you lose power, both will have to recover which could take 5-30 minutes.[1]
If you use MongoDB your DB apparently can get corrupted and you won't find out about for another month (link from article):
http://www.korokithakis.net/posts/using-mongodb-for-great-sc...
> If you have a 100 node cluster, worrying about every machine is a liability.
I see having to buy 100 nodes to get durability as a non-starter.
I mentioned this before and I'll say it again that calling their product a database and by default not returning write results is dishonest.
10gen employee (Kristina Chodorow) replying to the article admits that "We did this to make MongoDB look good in stupid benchmarks"
Well that's fine but then just call it rrdtool-ng
MongoDB is designed to be fast by default, which I like. But it can bite you.
I like its speed, and its interface, binary data (which saves disk space), and documentation. I'm not sure if it's data structure is sound though. I'd really like something with CouchDB's append only log, and MongoDB's interface (fast and easy), rich updates, and documentation.
People have lost and will lose their data. They see aha database [check], download [check], run benchmark [check], ok, put in production.
In the event of a single server crash, Mongo may need to be restored from backup, or another master. CouchDB handles this much better, and can just restart where it left off. But in the worst possible single-server scenario, there's smoke coming out of your server and the hard drive is toast. CouchDB and MongoDB perform about the same - if you had replication or a recent backup, you are fine. If you didn't, you are f*cked.
CouchDB is better for small servers which crash a lot and can't use replication. You can run it on a mobile phone. Mongo is better for logging (where you need fast writes, and don't care about a couple of lost records). Most uses will be somewhere in between, and you need to know the limitations of the stack, so you can work around them.
In the event of a crash, the journal will be replayed: http://www.mongodb.org/display/DOCS/Journaling
As noted, it's possible that will change in future releases; there's been a lot of improvements to journaling since its initial release.