For anyone thinking Berkeley DB, because it has transactions and logging, is a good replacement for an out-of-process DB, the answer is <i>no</i>.  Its embedded nature means that any &quot;client&quot; of a shared DB is free to deadlock the whole thing (if the client dies) or corrupt the database&#x27;s structure (if the client has a memory bug).<p>By the time you have a working robust multi-client system, you have completely reinvented half of what an RDBMS provides, since you will have pushed most functionality into a central server to avoid the lack of robustness its embedded nature brings, to simplify coordination of recovery when it (inevitably) crashes, and to centralize the rest of the infrastructure you have to build around it.<p>Its tools are crap: it can&#x27;t tell you how big a database is without traversing every single entry, they hold locks while writing to the terminal (meaning you can&#x27;t pipe them into a pager without freezing the whole DB), and if one of them crashes (due to e.g. a dropped SSH connection) they&#x27;ll bring down the whole DB due to stale locks.<p>Everything is underdocumented, especially the knobs you have to tweak to make it not run out of memory.  Its more &quot;advanced&quot; features are unusuably buggy.  Partition traversal (by cursor) is completely broken, and if you try to use partitions and key compression at once, things crash.  MVCC inexplicably keeps thousands of transactions open, causing out-of-memory issues.<p>Its C++ interface is a joke.  Somehow they managed to take an &quot;object-oriented&quot; C library, and jam it into C++ in a way that completely tosses all the benefits of C++&#x27;s object-orientedness.  RAII is <i>not</i> a concept the developers were familiar with: objects are created by factory functions and are variably and inconsistently freed by either their &quot;parent&quot; object, their own methods, and their destructors.  Do the wrong thing, and you trample memory, likely corrupting the database.  This is surprisingly easy due to the lack of documentation.<p>And my sympathy to anyone who tries to run SQLite on this bad boy… combined with SQLite&#x27;s shoddy track record interpreting any query more complicated than a key-value lookup, it would be a wonder if you&#x27;re able to get any data in and out intact.<p>Sorry for the rant.  Berkeley DB is many things, but a usable building block for a reliable RDBMS is not one of them.