The thing we see with CouchDB in production is that, although under low load we aren't the fastest kid on the block, as you ramp up concurrency (hundreds or tho

The thing we see with CouchDB in production is that, although under low load we aren't the fastest kid on the block, as you ramp up concurrency (hundreds or thousands of simultaneous clients) with mixed reads and writes, on a multi-GB database, we don't slow down. an old BBC case-study: http://www.erlang-factory.com/conference/London2009/speakers/endafarrell http://www.erlang-factory.com/conference/London2009/speakers... Building a test harness is non-trivial, Igal's tests are a lot like ones I used in the CouchDB book to illustrate the importance of batch updates, so I don't blame him for the imprecision. Right now the best test driver for CouchDB throughput looks to be Baracus: http://blog.cloudant.com/benchmarking-couchdb-with-baracus http://blog.cloudant.com/benchmarking-couchdb-with-baracus