I used PGLite for a project (monkeys.zip) and it was absolutely fantastic! Loved how speedily I could have a "real" postgres instance without spinning up docker. Worked really really well with pnpm workspaces and a monorepo setup (EG pnpm run will run the DB package, as well as frontend and backend).
The only downside (and this applies for SQLite as well) is that it runs too well that you can get some bad habits - or at least follow patterns that don't support horizontal scaling which you would want to do in production. A number of problems across different projects have bit me because I relied too long on SQLite (or PGLite) when moving from local dev to setting up cloud infra. This includes things like connection pooling, read replicas, consistency issues with sharding. Maybe all those people who productionize *Lite have a point!
This is why I built https://db4.app. This solves the biggest hurdle with using a PGLite instance from your browser, by giving you a universal postgres url. You can connect to it from anywhere with your credentials. Your data and queries are fully encrypted end-to-end. So it is only between your app, and your browser tab. Your data stays with you and db4.app provides the relay basically.
You can also host the Relay app yourself locally, if you'd like.
It comes with support for PG-vector, so you can use it for RAG in LLM Studio. We have a few MCP applications already built in the community apps section.
Unfortunately, when I tried to use it with https://github.com/wey-gu/py-pglite to speed up tests, I got stuck on it not being able to handle cell contents above a few thousand characters, which was a deal breaker for my project :(
I use pglite for unit/integration tests and it's been fantastic.
Note that it uses "single user mode." This means a single connection at a time, and thus no concurrent transactions. That takes you a little bit closer to SQLite's single-writer.
if you look merely for a replacement of SQLite i can higly recommend Firebird Embedded. it is faster, has better concurrency and has very low memory footprint
Quote: "... you just import ‘pglite’ in code, and you will have a fully-fledged Postgres instance writing to a local file, rather than a separate docker container..."
Because a docker container is a magic happening in heaven instead of being just another local file, right? /s
27 comments
The only downside (and this applies for SQLite as well) is that it runs too well that you can get some bad habits - or at least follow patterns that don't support horizontal scaling which you would want to do in production. A number of problems across different projects have bit me because I relied too long on SQLite (or PGLite) when moving from local dev to setting up cloud infra. This includes things like connection pooling, read replicas, consistency issues with sharding. Maybe all those people who productionize *Lite have a point!
IIRC it is intended to be read as SQL-ite, as having some relationship to SQL.
PG Lite probably makes sense here though, and PGite is not appealing
You can also host the Relay app yourself locally, if you'd like.
It comes with support for PG-vector, so you can use it for RAG in LLM Studio. We have a few MCP applications already built in the community apps section.
Happy to answer any questions.
Unfortunately, when I tried to use it with https://github.com/wey-gu/py-pglite to speed up tests, I got stuck on it not being able to handle cell contents above a few thousand characters, which was a deal breaker for my project :(
It’s a really solid piece of work. If the concurrency model fits what you’re doing I wouldn’t hesitate to use it in production.
How good is the testing for PGLite in comparison?
Is it only intended for test/development? (That’s still a useful use case if so, I love Postgres too).
Note that it uses "single user mode." This means a single connection at a time, and thus no concurrent transactions. That takes you a little bit closer to SQLite's single-writer.
> but only in javascript/WASM
Well that's right out then.
Because a docker container is a magic happening in heaven instead of being just another local file, right? /s