> He did go into several specifics as to why MongoDB might lose your data.

He was talking about that post http://www.korokithakis.net/node/119 that doesn't go into any specifics at all.

> Nice jab at CouchDB though!

But couchdb is slow though. I, like many, switched to mongodb because couchdb was just too slow and when I asked in IRC how to make it faster I was told to run a cluster of couchdb, so, not too different than mongodb ;)

For what it's worth, we've managed to make CouchDB about 10x faster (throughput, not latency) in the last year, and we're just getting started on the optimizations.

Care to share how? I'm really interested in what optimizations you did for this.

Probably the biggest one was cutting down on the amount of Erlang message passing that it takes to append a batch of data to the end of the db file.

There was also an Erlang configuration change which allowed us to make use of a thread pool for disk-io so that fsyncs didn't block other activity.

Really it was a bunch of tiny things, that all added up. The catalyst was the creation and use of a few highly-concurrent benchmark suites that we could use to identify bottlenecks.

it's easy to make something fast if you don't want durability, just look at memcached.