[shepik]

I've gone through picking embedded key-value store, too.

What really concerns me is why never in benchmarks they perform on already filled database (like, 14G, 28G, 60G)? Because "add 100k random keys into an empty database" is very different from "add 100k random keys into a large database". And that is where more novel algorythms start to shine.

Yes, read speed of leveldb (and, i assume, sophia) with its fancy sst's is lower than of plain old b-trees or hashtables (kctree/kchash), but it is still high enough for most tasks. Write performance of kc* (and btree-based libraries in general) is, however, unacceptable, at least on hard drives, and even with a reasonable-sized database (~90% of RAM) it degrades to a couple of random write per IOPs (so, 200-300 writes per second on a consumer-grade HDD, or up to 1000 on a 2x10k sas hdd in raid-0, if i remember correctly)

It may be reasonable to use kc* on SSD, but i did not test that.