I don't think it'd be terribly infeasible from an architectural standpoint because of the multi-process network architecture, but there are other things to consider. The multi-process architecture is really in it's favor, as it already uses IPC primitives (shared memory, semaphores) to share cache and control access to shared resources. The biggest barrier (I think) would be the file format. SQLite stores all of it's data in a single file (plus one temporary file for the journal). PostgreSQL's on-disk format would have to be heavily redesigned to support this, which I think is a huge advantage for SQLite.
Then again, there's no reason why an embedded database can't launch multiple subprocesses, or talk to itself via a socket for that matter. The same goes for the storage SQLite uses one file, but an embedded PostgreSQL allocating one opaque directory would be fine.
The important part is that you'd be able to easily statically link to it and handle permissions on a by-file basis, instead of PostgreSQL's current permission model. For all intents and purposes it'd be a larger SQLite replacement then.
Comments
I don't think it'd be terribly infeasible from an architectural standpoint because of the multi-process network architecture, but there are other things to consider. The multi-process architecture is really in it's favor, as it already uses IPC primitives (shared memory, semaphores) to share cache and control access to shared resources. The biggest barrier (I think) would be the file format. SQLite stores all of it's data in a single file (plus one temporary file for the journal). PostgreSQL's on-disk format would have to be heavily redesigned to support this, which I think is a huge advantage for SQLite.
Then again, there's no reason why an embedded database can't launch multiple subprocesses, or talk to itself via a socket for that matter. The same goes for the storage SQLite uses one file, but an embedded PostgreSQL allocating one opaque directory would be fine.
The important part is that you'd be able to easily statically link to it and handle permissions on a by-file basis, instead of PostgreSQL's current permission model. For all intents and purposes it'd be a larger SQLite replacement then.