Eh, you&#x27;re right on some and wrong on many other points. An embedded key-value store <i>can</i> be a good foundation for an RDBMS - or many other data models. The OpenLDAP Project used BerkeleyDB for more than 15 years. BerkeleyDB architects still point to OpenLDAP as a reference standard for transactional BDB code. <a href="http:&#x2F;&#x2F;www.bozemanpass.com&#x2F;services&#x2F;bdb.html" rel="nofollow">http:&#x2F;&#x2F;www.bozemanpass.com&#x2F;services&#x2F;bdb.html</a><p>As the primary author of OpenLDAP&#x27;s BDB support, and of the LMDB library which now supersedes BDB, I&#x27;ve got quite a deep perspective into this topic.<p>BDB is deadlock-prone, no argument there. But that doesn&#x27;t mean the embedded engine approach can&#x27;t work. LMDB is deadlock-proof, and serves perfectly well as the engine for an RDBMS as well as the engine for a hierarchical DB (X.500&#x2F;LDAP directory), or arbitrary graphs (<a href="http:&#x2F;&#x2F;sph.io&#x2F;content&#x2F;2faf" rel="nofollow">http:&#x2F;&#x2F;sph.io&#x2F;content&#x2F;2faf</a> , <a href="https:&#x2F;&#x2F;github.com&#x2F;pietermartin&#x2F;thundergraph" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pietermartin&#x2F;thundergraph</a> , etc...) etc. When you start with a model-less key&#x2F;value store you can implement <i>any</i> other data model on top.<p>LMDB&#x27;s robustness is, in a word, flawless. It&#x27;s crash-proof by design and multiple independent researchers have borne out the integrity of that design. (<a href="https:&#x2F;&#x2F;www.usenix.org&#x2F;conference&#x2F;osdi14&#x2F;technical-sessions&#x2F;presentation&#x2F;pillai" rel="nofollow">https:&#x2F;&#x2F;www.usenix.org&#x2F;conference&#x2F;osdi14&#x2F;technical-sessions&#x2F;...</a> <a href="https:&#x2F;&#x2F;www.usenix.org&#x2F;conference&#x2F;osdi14&#x2F;technical-sessions&#x2F;presentation&#x2F;zheng_mai" rel="nofollow">https:&#x2F;&#x2F;www.usenix.org&#x2F;conference&#x2F;osdi14&#x2F;technical-sessions&#x2F;...</a> ) Your assertion that you can&#x27;t build a robust multi-client system in a lightweight embedded system is flat wrong. In fact, this approach is the <i>only</i> way to get <i>maximum</i> performance from a software system. LMDB is so much faster than every other data management mechanism in existence, nothing else even comes close. <a href="http:&#x2F;&#x2F;symas.com&#x2F;mdb&#x2F;#bench" rel="nofollow">http:&#x2F;&#x2F;symas.com&#x2F;mdb&#x2F;#bench</a><p>Crap tools, crap locking - these are certainly weaknesses in BDB&#x27;s locking design. LMDB&#x27;s locking design doesn&#x27;t have these weaknesses. Querying the size of the DB is an O(1) operation, simply reading a few words out of the DB header.<p>Underdocumentation - I have no idea what you&#x27;re talking about here. To me, BDB was copiously documented, and I largely owe my understanding of transactional systems to the BDB documentation. Yes, BDB is complicated and has too many moving parts. LMDB doesn&#x27;t have this flaw either. But I can&#x27;t take anyone seriously who says BDB was underdocumented.<p>C++ interface - I don&#x27;t use C++, so no comment here.<p>C &gt;&gt; C++.<p>SQLite on BDB - yes, it&#x27;s a joke. I&#x27;ve run it, and the performance is pretty awful. But we do far better. <a href="https:&#x2F;&#x2F;github.com&#x2F;LMDB&#x2F;sqlightning" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;LMDB&#x2F;sqlightning</a><p>There are many positive and negative lessons in software design to be learned from Berkeley DB. It really started life as a test bed, for learning. In that, I think it succeeded admirably. Its authors were able to experiment with extensible hashing, B+trees, ARIES logging, and a multitude of other important software architecture and data management concepts. LMDB owes much of its design to lessons learned from BDB.<p>LMDB&#x27;s use of a read-only memory map by default means you can safely allow multi-client access without fearing corruption due to memory bugs. LMDB&#x27;s exclusive use of mmap instead of complex application-level caching means you avoid all of the horrors of BDB&#x27;s cache tuning, bloat driving into swap space, and other admin&#x2F;tuning nightmares. LMDB&#x27;s crash-proof persistent on-disk format means you don&#x27;t need to worry about error-prone and inherently unreliable transaction logging mechanisms. All of these features are part of the LMDB design because of our experience working with BDB over the past 15+ years.