I keep hoping that PostgreSQL will support an embedded version. SQLite only gets you so far, and it'd be nice to be able to ship PostgreSQL statically linked into your applications with zero-configuration at the user's end.
MySQL's working on this (http://mysql.com/oem/), but I've read that PostgreSQL is way too tied to their multi-process network architecture for this to be feasible. But I'd love to be shown to wrong on that.
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 keep hoping that PostgreSQL will support an embedded version. SQLite only gets you so far, and it'd be nice to be able to ship PostgreSQL statically linked into your applications with zero-configuration at the user's end.
MySQL's working on this (http://mysql.com/oem/), but I've read that PostgreSQL is way too tied to their multi-process network architecture for this to be feasible. But I'd love to be shown to wrong on that.
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.