alt.hn

4/9/2026 at 1:53:58 PM

PGLite Evangelism

https://substack.com/home/post/p-193415720

by surprisetalk

4/11/2026 at 12:45:24 AM

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!

by yathern

4/11/2026 at 8:00:20 AM

The biggest selling points for me with SQLite are how well tested it is and how well it scales to large data files.

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).

by Lio

4/11/2026 at 6:02:08 AM

Unfortunate name furthers the SQLite is "lite" association i.e. underpowered or incapable somehow.

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

by muti

4/11/2026 at 6:34:27 AM

I've always thought "lite" or light to mean non resource intensive to run, not necessarily less feature-rich.

by relatedtitle

4/11/2026 at 7:33:11 AM

> I wrote SQLite, and I think it should be pronounced "S-Q-L-ite". Like a mineral. But I'm cool with y'all pronouncing it any way you want. :-)

https://stackoverflow.com/a/49656730

So it’s actually not -lite but -ite. =)

by boramalper

4/11/2026 at 7:10:51 AM

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.

by jwilliams

4/11/2026 at 4:16:29 AM

Is there a feasible way to run this in a different language? (Go, in my case?)

by memset

4/11/2026 at 6:24:13 AM

It's in wasm so should be possible to code up the next language

by scirob

4/11/2026 at 5:53:23 AM

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

by trelliumD

4/11/2026 at 1:58:16 AM

Pgembed is pglite for native code.

by adsharma

4/11/2026 at 2:48:53 AM

Which one? https://github.com/Ladybug-Memory/pgembed or https://github.com/faokunega/pg-embed ?

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

https://github.com/f0rr0/pglite-oxide

by nextaccountic

4/11/2026 at 7:19:30 AM

frick this gotta be the tenth time ive read about pglite here and i always go look for native library. shame pr became stale, webapps simply arent always my end game. thanks for putting pglite-oxide on my radar tho, this is an interesting almost-there i can tinker with.

by trueno

4/11/2026 at 6:14:02 AM

I wonder, what amount of PG deployments can be replaced with SQLite. I bet most of them.

by Svoka