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
https://stackoverflow.com/a/49656730
So it’s actually not -lite but -ite. =)
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.
Both will either download or ship the postgres binary with your app, and run it in a separate process. Pglite is different, it's actually a library (they have stripped some parts of the postgres source code) and it could in principle be ported to be used as a native library (meaning, you link to it and run as a single program)
There's even a draft PR to do this, but it became stale
https://github.com/electric-sql/pglite/pull/842
Right now what exists is, grabbing the pglite wasm and running it on native code on wasi
Yes, what you get is a multi-server postgres under the covers. But for many users, the convenience of "uv pip install...", auto clean up via context manager is the higher order bit that takes them to SQLite.
Of course the bundled extensions are the key differentiator.
With enough distribution and market opportunities we (yes, there is a for profit company behind it) can invest in making it truly embedded.
If it has to write lots of stuff concurrently I use postgres.
And if I have even higher concurrency needs I write to redis and write an aggregator loop which writes to postgres every few seconds.
Because a docker container is a magic happening in heaven instead of being just another local file, right? /s