The WiredTiger configuration split percentage is explicitly set to 100; this should only be done in response to specific workloads and key/value insert patterns, and is almost certainly a bad idea in a benchmark.

The inner loop of couchstore_save_documents in every wrapper -- except ForestDB -- has a malloc/free pair and a bunch of memory copies.

Every wrapper -- except ForestDB -- gets two more malloc/free pairs and associated memory copies in the inner loop of couchstore_walk_id_tree, and WiredTiger gets another malloc and memory copy in couchstore_open_document nobody else has.

I won't speak for LevelDB or RocksDB, but any data copy is almost certainly unnecessary in WiredTiger's case.

At the least it would be utterly trivial to limit the malloc/free calls to a single call per set of documents or cursor traversal, or why aren't these buffers allocated per cursor?

The WiredTiger configuration is using small page sizes (4KB) with a relatively large default key/value size (550B). This is a bad idea; further, when larger key/value pair sizes are configured, the page/item sizes aren't adapted to match the larger key sizes.

Or maybe as another variant included in the benchmark?

-static int indexing_type = 0;
+static int indexing_type = 1;

Also, rocksdb has a prefix-db variant (better random-read perf) that could be included.

What are the transactional guarantees enforced by each of these engines/configurations? I'm asking because:

• WiredTiger is configured for both checkpointing and the logging, which may or may not make sense,
• WiredTiger's checkpoint frequency is configured to match the LSM engines' compaction frequency, which doesn't make sense,
• WiredTiger is logging to the same disk partition as the data store, which will significantly affect performance.

It could make sense to add Sophia, especially comparing the traversal case: http://sophia.systems/

http://sophia.systems/performance.html