This article is Emmanuel’s somewhat exhaustive comparison of LevelDB and Kyoto Cabinet. I guess he didn’t compare the others because he was only looking at cpp code. Anyways i’ll try to sum up the main points which really caught my eye in this article.

Parametrization: LevelDB takes the lead here, because it decoupled its implementation for the database from the parameters, and implemented instead a totally separate component for parameters (general, for read, for write), unlike Kyoto.

String: The main goal here is to get rid of O(n) when checking the size of a string, since at a huge scale, it becomes a real pain. So, the idea LevelDB had was to make a class which stores both the byte array and its size, so the size() method is O(1) in time. Redis does the same thing. Kyoto Cabinet uses std::string.

Error management : It will be inspired by LevelDB’s status object. We avoid unnecessary space if we just have a variable we need to set, in our case, it’s null unless something is wrong. And the error is treated by the Status class.

Memory management : Kyoto Cabinet uses a memory mapped file (meaning the OS handles virtual memory by itself- working set fits in RAM , otherwise the OS will have to access part of it it on disk)

Data storage : file system vs memcached (memcached stores everything in RAM)