Hello everyone, if this is the first time you're hearing about this library proposal, please start by reading the "Motivation" and "Approach" sections here: http://tinyurl.com/ct2vfp5 I've had some time to kill lately, so there are now working storage backends for BerkeleyDB and SQLite. Here's a simple example storing and modifying some objects in a BerkeleyDB: http://pastebin.com/yXJbTdz7 There is also a virtual interface that lets you decide which database to use at runtime, or dynamically link different DBMSs. You'll also be able to use multiple databases at once and have global transactions among them, if the DBMS supports two-phase commits. Are there any suggestions for other storage engines to support? If you are familiar with one you are also very welcome to contribute. The interface is very simple and no knowledge of library internals is needed. At this point storage engines to support should be: - transactional. There is code for a MVCC transaction layer from my own storage engine, but it's not generic enough yet to just put it on top of a non-transactional engine like google's LevelDB. - good at handling BLOBs to store serialized objects. Object/Relational mapping is a whole other project. - preferrably have a very free license. The BerkeleyDB code is seperated from the rest so I don't think there are problems with the GPL-like license "infecting" the entire library if you don't use it. But if you do, it's GPL or commercial. I've looked at Tokyo Cabinet in some detail, but it seems more like a collection of functions to me, that one could use to build a DB with, than a robust product. I would like to be proven wrong on this, as it's often compared to BerkeleyDB and is LGPL-licensed. Suggestions for other embedded databases that could be supported are also welcome. Best regards, Stefan