OK, for your sequential synchronous random write case, LMDB is fair-to-middling. In fully-synchronous mode (which is the default) it takes 2 fsyncs per transaction, so at least 2 IOPS per write. Many other DBs (including SQLite, Berkeley, and Kyoto) take even more than 2 fsyncs per transaction, and are slower than LMDB. Some others take only 1, and are much faster in this workload.<p>LMDB outperforms all other engines on larger-than-RAM DBs with page-sized objects because its zero-copy architecture doesn&#x27;t waste any RAM. For other DBs you must dedicate some fraction of RAM to write buffers and page caches in order to obtain their maximum performance. This means the largest working set size they can keep in RAM is much smaller than the actual physical RAM. With LMDB there are no separate write buffers or caches, all of available RAM can be utilized for your working set. This is precisely the scenario tested here <a href="http:&#x2F;&#x2F;symas.com&#x2F;mdb&#x2F;hyperdex&#x2F;" rel="nofollow">http:&#x2F;&#x2F;symas.com&#x2F;mdb&#x2F;hyperdex&#x2F;</a><p>I&#x27;ll note that in that test, LMDB performed at exactly the disk read seek rate; HyperLevelDB&#x27;s LSM performed at much worse than that rate.