There is no reason why you cannot do concurrent transactional writes in embedded database library and there are many embedded databases that can do that. MySQL

There is no reason why you cannot do concurrent transactional writes in embedded database library and there are many embedded databases that can do that. MySQL is probably only opensource client-server RDBMS whose server is based on relatively tightly coupled threads. PostgreSQL uses separate processes with well defined IPC interface between them, for long time the postmaster process mostly served to initialize and teardown this IPC interface (apart from spawning postgres processes for incomming connections), which was mostly needed because SysV IPC is brain-dead, hacking PostgreSQL into embedded library is probably not advisable, but perfectly doable. Firebird's architecture is similar, but in addition explicitly supports use as embedded library and stores whole database in single file, that can be used by both server daemon and embedded library at the same time (and the file can even reside on windows share without compromising transactional semantics). Main problem with doing fine grained locking in embedded library (apart from complexity of fine grained locking itself) is with various non-standard situations like crash recovery. Another problem is that when processes that access the database data run under different users, there is real possibility of data corruption caused by wrong permissions or some similar misconfiguration (perfect example of this were first versions of subversion with Berkeley DB backend).