…I don&#x27;t quite understand why you rebutted my points about Berkeley DB with points about LMDB.<p>The only point you actually rebutted without referring to LMBD was regarding documentation.  Yes, <i>some</i> parts of BDB are copiously documented.  Others are not.  How cursors interact (or, don&#x27;t) with partitioning is not documented at all.  Some settings are underdocumented (e.g. the cache size setting doesn&#x27;t specify whether &quot;gigabytes&quot; means 10^9 or 2^30).  What the cache priority levels mean is barely even discernible from the source code.  The documentation for how to set parameters like the total number of mutexes and active transactions to allocate boils down to &quot;guess and check&quot;.  Why enabling MVCC causes transactions to linger for ages isn&#x27;t explained anywhere, beside maybe one mailing list post from 2008.<p>I&#x27;m glad to see that my experience with BDB is corroborated by that of the developer of BDB&#x27;s poster child (despite your unsubstantiated claim that I&#x27;m &quot;wrong on so many points&quot;).<p>That said, since you felt the need to claim it, I feel the need to ask how you can rectify the claim that &quot;LMDB is so much faster than every other data management mechanism in existence, nothing else even comes close&quot; with the fact that LMDB is Btree-based and thus must face significant performance challenges with both sequential synchronous random writes, and with random writes and deletes to&#x2F;from databases whose working set does not fit in memory.