PGlite – Embeddable Postgres
Posted by dsego 7 days ago
Comments
Comment by samwillis 7 days ago
If you have any questions I'll be sure to answer them.
We recently crossed a massive usage milestone with over 3M weekly downloads (we're nearly at 4M!) - see https://www.npmjs.com/package/@electric-sql/pglite
While we originally built this for embedding into web apps, we have seen enormous growth in devtools and developer environments - both Google Firebase and Prisma have embedded PGlite into their CLIs to emulate their server products.
Comment by mpweiher 7 days ago
Obviously missing something...
Comment by OvbiousError 7 days ago
Comment by mpweiher 7 days ago
Comment by mirrir 7 days ago
Comment by embedding-shape 7 days ago
Comment by dboreham 7 days ago
Comment by hombre_fatal 7 days ago
Looking at the repo, it started as postgres-in-the-browser. An abstract interface with C and wasm as targets is just more scope.
But it looks like the hard part of patching postgres to librar-ify it is already done agnostically in C.
So you just need to ctrl-f for "#if defined(__EMSCRIPTEN__)" to impl those else branches and port the emmake file to make.
Comment by monster_truck 7 days ago
Comment by intrasight 7 days ago
Comment by saurik 7 days ago
Comment by SteveLauC 7 days ago
Comment by tdrz 6 days ago
Comment by DonnyV 7 days ago
If anyone wants to help out who has compiled the postgis extension and is familiar with WASM. You can help out here. https://github.com/electric-sql/pglite/pull/807
Comment by nnnnico 7 days ago
Comment by tdrz 6 days ago
Comment by JackC 7 days ago
Is the project interested in supporting http-vfs readonly usecases? I'm thinking of tools like DuckDB or sql.js-httpvfs that support reading blocks from a remote url via range requests.
Curious because we build stuff like this https://news.ycombinator.com/item?id=45774571 at my lab, and the current ecosystem for http-vfs is very slim — a lot of proofs of concept, not many widely used and optimized libraries.
I have no idea if this makes sense for postgres — are the disk access patterns better or worse for http-vfs in postgres than they are in sqlite?
Comment by phplovesong 7 days ago
Comment by sgt 7 days ago
Comment by oulipo2 7 days ago
Comment by tdrz 7 days ago
Comment by samwillis 7 days ago
Comment by rel 7 days ago
Comment by glenjamin 7 days ago
If so then supporting the network protocol so it could be run in CI for non-JS languages could be really cool
Comment by jitl 7 days ago
Comment by allan_s 7 days ago
Comment by mentalgear 7 days ago
Comment by dcgudeman 6 days ago
Comment by TheDataMaverick 7 days ago
Comment by lame_lexem 7 days ago
Comment by tln 7 days ago
In my case, the focus is on DX ie faster tests. I load shared database from `pglite-schema.tgz` (~1040ms) instead of running migrations from a fresh DB and then use transaction rollback isolation (~10ms per test).
This is a lot faster and more convenient than spinning up a container. Test runs are 5x faster.
I'm hoping to get this working on a python service soon as well (with py-pglite).
Comment by TheTaytay 7 days ago
Comment by reachableceo 7 days ago
How do you know how many deployments you actually have in the wild?
Comment by pixelatedindex 7 days ago
Additionally, how you can get data on how many deployments without telemetry? The only telemetry that I’m interested in is for my uses, and don’t really care about sending data on deployment count to a third party. So the download count becomes a “good enough” metric.
Comment by bbkane 7 days ago
https://github.com/electric-sql/pglite/issues/89 makes it sound like there's "third-party" bindings for Rust. Is there any interest in "official" PGLite bindings to other languages?
Comment by papa0101 7 days ago
Comment by spicypixel 7 days ago
Comment by buremba 7 days ago
The result is a PG server that fully lives in your browser: https://dbfor.dev
Comment by nextaccountic 5 days ago
Comment by buremba 4 days ago
The hard work is done by PGlite and we use PGlite, it just enables PGlite to be accessible from everywhere.
Comment by _fzslm 7 days ago
But I read the following posts, and I have some serious concerns about PGlite's performance:
https://antoine.fi/sqlite-sync-engine-with-reactivity – describes memory leaks, minute-long db startup time, and huge slowdowns with live queries
https://github.com/marcus-pousette/sqlite3-bench - shows performance dropping to multi-second territory for inserts and lookups, compared to sqlite which is significantly faster
It sadly makes me slightly skeptical about adopting what effectively feels like a hack... SQLite has obviously had decades of adoption and I'm not expecting PGlite to match that level of legacy or optimisation - but it's enough to give me pause.
I really, really want to adopt PGlite in a project I'm currently architecting, so would love some insight on this if anybody has any!
Comment by oamaok 7 days ago
The ability to .clone() the database to create "checkpoints" is also great for tests, as we can run all of the migrations and return to that clean state between each test. Running 50 test suites in parallel is also so easy with this setup.
Comment by dvdkon 7 days ago
Is there a way to compile this as a native library? I imagine some of the work should be reusable.
Comment by evelant 7 days ago
Comment by samwillis 7 days ago
Comment by patwolf 7 days ago
Comment by evelant 7 days ago
Comment by worthless-trash 7 days ago
Imagine being able to go from 'embedded' to 'networked' without having to change any SQL or behavior, so cool.
Comment by tdrz 7 days ago
Comment by odie5533 7 days ago
Comment by theptip 7 days ago
Comment by widenrun 7 days ago
Comment by nunobrito 7 days ago
I've never used Postgres before, my work is mostly on the embedded domain using files and a lot of browser execution on the client side.
With SQLite there is simplicity attached to the databases, with PGLite I see a lot of interesting extensions to try out but what would the big difference when compared to SQLite?
Comment by richbell 7 days ago
Comment by CyberDildonics 7 days ago
Comment by Fuzzwah 7 days ago
Not that testing is the main use of sqlite.
Comment by trillic 7 days ago
Comment by lateforwork 7 days ago
Comment by adhamsalama 7 days ago
Here's the project if anyone is interested: https://github.com/adhamsalama/sqlite-wasm-webrtc
Comment by avinassh 7 days ago
Comment by bhouston 7 days ago
Impressive performance: https://pglite.dev/benchmarks
Even has Drizzle ORM integration: https://orm.drizzle.team/docs/connect-pglite
I will explore this for use in my unit / integration tests. It looks pretty amazing.
I am confused why all my recent compiled tooling (tsgo, biomejs) are shipping native binaries (thus creating multiple binaries, one per supported platform) and not WASM tools that can run cross platform? Is it because of startup times, poor tooling, etc?
Comment by jitl 7 days ago
Comment by TonyAlicea10 7 days ago
AI-generated code that doesn’t need to be production ready has been a real boon to usability and design work. Testing with users something that actually saves and displays data, and seeding the app with realistic-looking datasets in both shape and size, reveals usability issues that you just don’t discover in Figma prototypes.
If a product team isn’t performing user research with interactive prototypes as a core part of their dev and design lifecycle, they’re doing themselves a real disservice. It’s so easy now.
Comment by stacktrace 7 days ago
For a few edge-case scenarios we ended up mocking the DB layer (which obviously stops being a true e2e test). Something like PgLite would've been a perfect middle ground - real Postgres, zero container overhead, easy to spin up isolated instances per test, and a clean slate for every run.
Comment by kburman 7 days ago
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?
Comment by samwillis 7 days ago
Comment by sigseg1v 7 days ago
Comment by korale 6 days ago
Comment by tdrz 7 days ago
Comment by jherdman 7 days ago
Comment by replwoacause 7 days ago
Comment by Robdel12 7 days ago
Now, I just tested against a real database in a docker container. I have over 1k tests that run about 1.5 mins. I’m pretty happy with that.
I guess given that, testing isn’t quite the use case for this (for me). Wonder what else this could be used for.
Comment by manzout 7 days ago
Comment by huzaifah0x00 7 days ago
Definitely going to try this out for tests and see how it goes.
Comment by RichardChu 7 days ago
I've been using SQLite locally instead with wa-sqlite and it's been working great for my use case so far. It's also more lightweight.
Comment by eduction 7 days ago
(Not doubting your claim this just seems one of those words that means many different things depending on the context.)
Comment by RichardChu 7 days ago
Comment by exceptione 7 days ago
Nonetheless, this could be interesting for data heavy SPA's.
Comment by samwillis 7 days ago
Extensions are also available - we have a list here: https://pglite.dev/extensions/. We would love to extend the availability of more, some are more complex than others though. We are getting close to getting PostGIS to work, there is an open PR that anyone is welcome to pick up and hack on.
Comment by compoundedges 7 days ago
We are not syncing with Electric, but I've heard good things about it.
Comment by mythz 7 days ago
Comment by samwillis 7 days ago
Comment by t_mahmood 7 days ago
Having something like this, that I can quickly spawn and know, I am getting exact behavior as prod database would be a lifesaver!
Comment by npodbielski 7 days ago
Comment by ekjhgkejhgk 7 days ago
Why not just sqlite then?
Comment by somat 7 days ago
Comment by vincnetas 7 days ago
Comment by rozenmd 7 days ago
Comment by aperture147 7 days ago
Comment by mrinterweb 7 days ago
Comment by tdrz 6 days ago
Comment by throw_m239339 7 days ago
Comment by alexisread 7 days ago
Comment by samwillis 7 days ago
Comment by guardian5x 7 days ago
Comment by lgas 7 days ago
Comment by STRiDEX 7 days ago
Comment by Drakim 7 days ago
Despite being a native feature to the browser it's incredibly slow, and the way it works in terms of fetching records based on non-primary keys forces you to either load your entire dataset into RAM at once or iterate though it record-by-record in a slow callback. Something as trivial as 10k records can bring your webapp to a crawl.
Comment by orthecreedence 7 days ago
Comment by lionelholt 2 days ago
Comment by cosmotic 7 days ago
Comment by samwillis 7 days ago
Comment by urtie 7 days ago
Ofcourse, that ignores the fact that for many of these languages there are existing libraries and drivers to connect to databases that would not work with this embedded one, but still.
Comment by ianberdin 7 days ago
I have built a playground for it today: https://playcode.io/sql-editor
(Full feature set, including extensions, pgdump, database explorer, indexedDB, vscode editor, etc). Free. No ads. No bs.
Comment by iamcreasy 7 days ago
Comment by tmikaeld 7 days ago
At this point, this should be built into the browser which could fetch signed db data and be extremely performant.
Comment by qazswx 7 days ago
Comment by u834957920 7 days ago