For me, the answer is "no". Otherwise, I'd invest further time in a proper review.
Same here.
But if I want a fast, disk-based database, I'll use sqlite - which does a lot more for me - not go straight to the filesystem.
Or, something like Redis, because it is fast, established, and most importantly is cluster-ready. (*) (Given that Redis and most competitors are on BSD or Apache open source licenses, it seems hard to justify anyone writing their own key-value store.) This library feels like it should be a github library, so that people trying to optimize SQLite, Redis, etc. can dip into the useful knowledge that is contained in it. Darren * If a high-end server running a key-value store can support N transactions/second, I don't want to replace the key-value store with one that can support 1.1N transactions/seconds, or even 2N transactions/seconds. I want one that is easy to spread over 10 servers so I can support 10N transactions/second.