This looks impressive. Could someone familiar with Postgres internals explain the hidden trade-offs of this approach?

I understand the obvious limitations of it being embedded/single-host, but I'm curious about the engine itself. Does running in this environment compromise standard features like ACID compliance, parallel query execution, or the ecosystem of tools/extensions we usually rely on?

▲

samwillis 8 hours ago | parent | next [-]

The key limitation (at the moment) is that it only supports a single connection. W're planning to lift that limitation though.

	▲	sigseg1v 5 hours ago \| parent [-]
		This is what I'm most interested in. I have an application which has a smaller trimmed down client version but it shares a lot of code with the larger full version of itself. Part of that code is query logic and it's very dependent on multiple connections and even the simplest transactions on it will deadlock without multiple connections. Right now if one wants to use the Postgres option, it needs Postgres manually installed and connected to it which is a mess. It would be the dream to have a way to easily ship Postgres in a small to medium sized app in a enterprise-Windows-sysadmin-friendly way and be able to use the same Postgres queries.

▲

tdrz 8 hours ago | parent | prev [-]

You might want to have a look at our extensions catalog page: https://pglite.dev/extensions/