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.
Why not just sqlite then?
Having something like this, that I can quickly spawn and know, I am getting exact behavior as prod database would be a lifesaver!
Is there a way to compile this as a native library? I imagine some of the work should be reusable.
Imagine being able to go from 'embedded' to 'networked' without having to change any SQL or behavior, so cool.
Here's the project if anyone is interested: https://github.com/adhamsalama/sqlite-wasm-webrtc
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.
How do you know how many deployments you actually have in the wild?
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.
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).
Obviously missing something...
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.
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?
If so then supporting the network protocol so it could be run in CI for non-JS languages could be really cool
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
Nonetheless, this could be interesting for data heavy SPA's.
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.
We are not syncing with Electric, but I've heard good things about it.
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?
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.
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.
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?
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.
Definitely going to try this out for tests and see how it goes.
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.
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?
At this point, this should be built into the browser which could fetch signed db data and be extremely performant.
The result is a PG server that fully lives in your browser: https://dbfor.dev
The hard work is done by PGlite and we use PGlite, it just enables PGlite to be accessible from everywhere.
Perhaps once generally true, not as true since .NET Core.
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.
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!
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.
(Not doubting your claim this just seems one of those words that means many different things depending on the context.)
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?
Not that testing is the main use of sqlite.
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.
avinassh•2mo ago