Reliability and data integrity

[torabian]

Sorry to sound a bit cliche,
But I was wondering to things.

1- Does the data created using pglite, consumable directly, with original postgres, or even at the same time? There is a go wrapper which can use pglite directly in Go. I was wondering in a desktop app, can they be used?

2- How reliable is using pglite for desktop, can it be considered a production level, for non critical desktop application, or maybe an internal server on a raspberry pie?

Many thanks for the work, this kinda makes usage of postgres where only option was traditionally SQLITE.

[tdrz]

1- Does the data created using pglite, consumable directly, with original postgres

Data created with PGlite is consumable by an original Postgres installation (with a matching version!).

SELECT version(); in our online REPL:

or even at the same time?

Unsure what this means.

There is a go wrapper which can use pglite directly in Go. I was wondering in a desktop app, can they be used?

Native PGlite support is on our TODO list. There is no official Go wrapper that we support or endorse atm.

2- How reliable is using pglite for desktop, can it be considered a production level, for non critical desktop application, or maybe an internal server on a raspberry pie?

PGlite is still considered beta as it only runs in single-user mode and has various other (inherent) limitations. Nevertheless, there are plenty of users that deploy it on all kinds of environments.

[torabian]

How would we commit the data into the the project? I understand that we can do use IndexDB, but similar to a .db file in sqlite, is there an option, to commit the database, and modify it locally, and then commit so in web it would consume data?

It's super cool though. I have exposed the pglite query over wasm to golang, so full server now works.

https://torabian.github.io/emi/in-browser-server

It would be nice to have database created prior to loading of page, such as seed content.

[tdrz]

How would we commit the data into the the project?

You can use pg_dump in PGlite to dump an instance and use the result on a new one.

It would be nice to have database created prior to loading of page, such as seed content.

That's what our pglite-prepopulated package does. You can use the same approach to seed your own database.

[ryangu00]

On (2) — the reliability question, which I don't think has been covered yet.

Context for where this comes from: gbrain (an open-source personal-knowledge tool I contribute to) ships PGLite as its zero-config default engine, with Postgres as the alternative for larger installs. Same schema, same migrations, both engines. So the edges below are things that surfaced in its issue tracker and are now handled explicitly in its PGLite adapter — not theory, but also not a claim that PGLite ate anyone's data. It didn't.

Short answer: yes for a desktop app or an internal box, with a few sharp edges worth knowing up front.

Single writer, enforced by a lock on the data dir. This is the one that bites architectures, not data. PGLite holds an exclusive lock on its data directory, so a second process cannot connect while the first holds it. Fine for a single-process desktop app. Not fine if you have, say, a GUI and a CLI that both want the same dir — you need one owner and an IPC path for the other, or separate dirs.

Release the lock on every exit path. If your close/teardown throws before the lock is released, the next start has to wait it out. Worth wrapping teardown in try/finally so the release always happens, and making disconnect idempotent so a double-call doesn't clobber a fresh connection. Related: if you null out the handle before any await in your close path, a concurrent connect can't observe a half-closed state.

The WASM runtime can fail to init for platform reasons that have nothing to do with your code. Two we've seen classified separately: a macOS-version-specific WASM issue, and bundler paths (packaging with Bun puts the data file behind a virtual FS, so init fails with ENOENT on pglite.data). Both look identical from the outside — an opaque PGlite.create() throw — so it's worth classifying the error and printing a distinguishing hint, otherwise every platform bug gets misdiagnosed as the same one.

Process exit. The WASM instance can keep the host event loop alive, so a CLI that finishes its work may not exit until you disconnect. If you have fire-and-forget writes in flight, drain them before disconnecting or you'll race.

On (1), adding to what tdrz said: the version-match caveat is the load-bearing part. The data directory is a real Postgres data dir, so a matching-version server reads it — but you're then on the hook for keeping those versions aligned across your app's releases, which is a real maintenance cost if the desktop app and the server upgrade on different schedules. Concurrent access from both at once runs into the same single-writer lock above.

For a Raspberry Pi internal server: the constraint I'd check first isn't reliability, it's that you're running Postgres compiled to WASM. Measure your workload rather than assuming it matches native Postgres.