Is there any interest to include a persistence library in boost, built upon the boost serialization library? the basic idea is: transaction tx; change_objects(); tx.commit(); all changes made by change_objects() should be undone if tx is destroyed without calling commit(), e.g. because of an exception thrown by change_objects(). the library should provide ACID transaction properties, so that multiple transactions (in different threads) can work on the same objects and conflicts are discovered by the library. further, an application crash should be recovered, with the changes made by a transaction either committed as a whole or undone. to partition your object model into many different objects, which can be saved to disk and loaded back on demand, there is a new smart pointer introduced, which behaves like smart_ptr and is convertible to smart_ptr. objects that are handled by this smart pointer and are no longer used in memory are not destroyed but saved to disk. only objects which are no longer in use either in memory or on disk are destroyed. the only requirement on persistent objects would be to model the concept "Serializable" as defined by boost serialization. e.g. a linked list, whose elements are loaded from disk on demand could look like: struct node{ db_ptr<node> next; private: //Serializable requirements }; void traverse(){ while(current) current=current->next; //operator-> loads the next node } prototype implementation --- i've attached a test case using the current implementation. it demonstrates multiple concurrent transactions.running isolated from each other. it models a bank, with multiple threads constantly withdrawing from one (random) bank account and depositing the amount on another. when two threads are using the same bank account at the same time, resulting in money being lost, an isolation_exception is thrown in one of the threads and the transaction can be restarted. there is no manual thread synchronization involved. the current implementation uses an optimistic multiversion approach, meaning that each transaction running concurrently is working on its own copy of an object. when the transaction is committed conflicts are discovered and an isolation_exception is thrown. several things like reference counting on disk and the recovery process after a crash aren't implemented yet, but the basics are in place and should give you an idea of what kind of a library I'm proposing.