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.
If I understand correctly, what this project does is take the actual postgresql sources, which are written in C, compile them to wasm and provide typescript wrappers. So you need the wasm to be able to use the C code from js/ts.
Yeah... I was super excited by this project when it was first announced--and would even use it from Wasm--but since it ONLY works in Wasm, that seemed way too niche.
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?
This is awesome, thanks for your work!
Could this work with the file system api in the bowser to write to user disk instead of indexeddb? I'm interested in easy ways for syncing fot local-first single user stuff <3 thanks again
I'm interested to use Pglite for local unit-testing, but I'm using timescaledb in prod, do you think you will have this extension pre-built for Pglite?
I'm not aware of anything trying to compile timescale for it. Some extensions are easer than other, if there is limited (or ideally no) network IO and its written in C (Timescale is!) with minimal dependencies then its a little easer to get them working.
At work we started building a new internal service and decided to try this out for the test setup. We built a small wrapper which seamlessly uses PGLite when running tests and actual Postgres instance otherwise. Great success!
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.
This is very cool. Having to always set up a server is one major downside of Postgres, with cumbersome updates being the second. This solves the first and has potential to help with the second.
Is there a way to compile this as a native library? I imagine some of the work should be reusable.
Glad to see it working in react native. It always surprises me that RN doesn't natively support wasm. I've had to avoid other wasm-based libraries, like loro, for that reason.
Yeah, it's unfortunate but it's not really react-native/facebook's fault. Apple doesn't allow any sort of JIT to run on iOS outside of their builtin webkit js engine. That means that AFAIK there's no way to run wasm at reasonable speed on iOS, which means react-native can't really support wasm.
Using this for testing... it feels like a sweet spot between in-memory SQLite and spinning up a full Postgres instance. I'd been looking for this for a while and I'm pretty happy with the faster tests. And so far no blockers from its limitations.
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?
This looks impressive. Could someone familiar with Postgres internals explain the hidden trade-offs of this approach?
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?
This is interesting, I've been looking for something like this that I can use in unit/integration tests. I've used the mongodb memory server for testing but never found something like that for Postgres that didn't require running a full PG server instance...
Definitely going to try this out for tests and see how it goes.
Really cool project! We had a situation a while back where some of our e2e tests needed the DB to be in very specific states. Technically we could have handled it with fixtures/transactions/schema resets, but doing that cleanly across a bunch of tests was pretty painful in our setup at the time
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.
I'm using this with a Bun project for my testing needs. I spin PGLite at the beginning, throw it all away at the end. It's not as nice as transactionally isolated testing (a la Ruby on Rails, or Elixir), but it's a fine replacement until I have time to replicate it.
Are people using this in SPA applications with success? I saw on the website that syncing via ElectricSQL is in alpha and that no CRDT is available, afaik. Any other options?
Also, I guess pgsql extensions are out of scope?
Nonetheless, this could be interesting for data heavy SPA's.
There are a few people using it in prod for customer facing web apps.
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.
One thing this (and any browser-embeddable data store) are fantastic for is vibe coding interactive prototypes for user research.
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.
It's now used by a huge number of developers for running local dev environments, and emulating server products (Google firebase and Prisma both embed it in their CLI). Unit testing postgres backed apps is also made significantly easer with it.
One use case, when doing unit tests, Docker containers, would make it too expensive with many tests. SQLite's type checking is far less strict than Postgres, which would not catch errors that would occur the real database due to type mismatch.
Having something like this, that I can quickly spawn and know, I am getting exact behavior as prod database would be a lifesaver!
Hmm single user website run as HTML from some folder? I guess you could embed this from s3 for multiple users but probably this would be like running multiple engines from the same dir.
Postgres features are much nicer, honestly if you are using any sort of orm none of this matters. by design they isolate you from many of the more interesting features of the database. And in general this is probably a good thing. But if you enjoy hand writing artisanal sql postgres is far more pleasant to use than sqlite, not that sqlite is bad, it is very good, just... thin after using pg.
I was shocked to discover how incredibly poorly IndexedDB works. I always thought it would be fast and snappy if a bit alien. But nope, it's incredibly bad!
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.
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.
We have a long on running research project with the intention of carting a "libpglite" with a C FFI and compiled as a dynamic library for native embedding. We're making steady progress towards it.
I tried to use this when I was building a project about peer-to-peer database sharing in the browser using WebAssembly and WebRTC, but I found it a bit heavy so I used SQLite instead.
Hey everyone, I work on PGlite. Excited to see this on HN again.
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.
This looks really interesting...but why WASM-only? Naively it seems like WASM-ification would be a 2nd step, after lib-ification.
Obviously missing something...
If I understand correctly, what this project does is take the actual postgresql sources, which are written in C, compile them to wasm and provide typescript wrappers. So you need the wasm to be able to use the C code from js/ts.
Yes. I would like to use the code as a library from something other than js/ts.
Yeah... I was super excited by this project when it was first announced--and would even use it from Wasm--but since it ONLY works in Wasm, that seemed way too niche.
WASM means you only need to develop for one target run time. That's my guess as to why.
Thanks for your work!
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?
Does pglite in memory outperform “normal” postgres?
If so then supporting the network protocol so it could be run in CI for non-JS languages could be really cool
This is awesome, thanks for your work! Could this work with the file system api in the bowser to write to user disk instead of indexeddb? I'm interested in easy ways for syncing fot local-first single user stuff <3 thanks again
This looks REALLY awesome. Could you name a few usecases when i would want to use this. Is the goal to be an sqlite/duckdb alternative?
Amazing work! It makes setting up CI so much easier.
huh. could you tell how you use it in ci?
Well downloads doesn’t equal usage does it ?
How do you know how many deployments you actually have in the wild?
Yupp, this has big potential for local-first !
I'm interested to use Pglite for local unit-testing, but I'm using timescaledb in prod, do you think you will have this extension pre-built for Pglite?
We have a walk-through on porting extensions to PGlite: https://pglite.dev/extensions/development#building-postgres-...
I'm not aware of anything trying to compile timescale for it. Some extensions are easer than other, if there is limited (or ideally no) network IO and its written in C (Timescale is!) with minimal dependencies then its a little easer to get them working.
I’ve had incredible success with testcontainers for local unit-testing
At work we started building a new internal service and decided to try this out for the test setup. We built a small wrapper which seamlessly uses PGLite when running tests and actual Postgres instance otherwise. Great success!
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.
This is very cool. Having to always set up a server is one major downside of Postgres, with cumbersome updates being the second. This solves the first and has potential to help with the second.
Is there a way to compile this as a native library? I imagine some of the work should be reusable.
Yes! I (experimentally) compiled and packaged it for react-native. Postgres on iOS and Android https://github.com/electric-sql/pglite/pull/774
This is such awesome work! We *are* going to get this integrated with the ongoing work for "libpglite".
Glad to see it working in react native. It always surprises me that RN doesn't natively support wasm. I've had to avoid other wasm-based libraries, like loro, for that reason.
Yeah, it's unfortunate but it's not really react-native/facebook's fault. Apple doesn't allow any sort of JIT to run on iOS outside of their builtin webkit js engine. That means that AFAIK there's no way to run wasm at reasonable speed on iOS, which means react-native can't really support wasm.
Native library is on our radar!
Took the words out of my mouth, i can think of many use cases for this.
Imagine being able to go from 'embedded' to 'networked' without having to change any SQL or behavior, so cool.
There is also Doltgres [1] which is a single-file Postgres. Just like Deno you download and run a single .exe file and voila! you have Postgres!
[1] https://docs.doltgres.com/introduction/installation
Using this for testing... it feels like a sweet spot between in-memory SQLite and spinning up a full Postgres instance. I'd been looking for this for a while and I'm pretty happy with the faster tests. And so far no blockers from its limitations.
Very neat.
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?
previous Show HN post submitted by the author (109 comments) - https://news.ycombinator.com/item?id=41224689
This looks impressive. Could someone familiar with Postgres internals explain the hidden trade-offs of this approach?
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?
The key limitation (at the moment) is that it only supports a single connection. W're planning to lift that limitation though.
You might want to have a look at our extensions catalog page: https://pglite.dev/extensions/
This is interesting, I've been looking for something like this that I can use in unit/integration tests. I've used the mongodb memory server for testing but never found something like that for Postgres that didn't require running a full PG server instance...
Definitely going to try this out for tests and see how it goes.
Really cool project! We had a situation a while back where some of our e2e tests needed the DB to be in very specific states. Technically we could have handled it with fixtures/transactions/schema resets, but doing that cleanly across a bunch of tests was pretty painful in our setup at the time
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.
I'm using this with a Bun project for my testing needs. I spin PGLite at the beginning, throw it all away at the end. It's not as nice as transactionally isolated testing (a la Ruby on Rails, or Elixir), but it's a fine replacement until I have time to replicate it.
Are people using this in SPA applications with success? I saw on the website that syncing via ElectricSQL is in alpha and that no CRDT is available, afaik. Any other options? Also, I guess pgsql extensions are out of scope?
Nonetheless, this could be interesting for data heavy SPA's.
There are a few people using it in prod for customer facing web apps.
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.
One thing this (and any browser-embeddable data store) are fantastic for is vibe coding interactive prototypes for user research.
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.
It's cool that this is possible, is this just for fun or are there good use-cases for this?
It's now used by a huge number of developers for running local dev environments, and emulating server products (Google firebase and Prisma both embed it in their CLI). Unit testing postgres backed apps is also made significantly easer with it.
One use case, when doing unit tests, Docker containers, would make it too expensive with many tests. SQLite's type checking is far less strict than Postgres, which would not catch errors that would occur the real database due to type mismatch.
Having something like this, that I can quickly spawn and know, I am getting exact behavior as prod database would be a lifesaver!
I use it for realistic(ish) testing of my hono API, big fan
Hmm single user website run as HTML from some folder? I guess you could embed this from s3 for multiple users but probably this would be like running multiple engines from the same dir.
> Hmm single user website run as HTML from some folder?
Why not just sqlite then?
Postgres features are much nicer, honestly if you are using any sort of orm none of this matters. by design they isolate you from many of the more interesting features of the database. And in general this is probably a good thing. But if you enjoy hand writing artisanal sql postgres is far more pleasant to use than sqlite, not that sqlite is bad, it is very good, just... thin after using pg.
More SQL functionality?
What is the advantage of using something like this instead of the IndexedDB Browser Feature
You get all the features of postgres.
I was shocked to discover how incredibly poorly IndexedDB works. I always thought it would be fast and snappy if a bit alien. But nope, it's incredibly bad!
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.
Can this be used as a read-replica to a normal PG instance? I'm thinking synced browser cache here.
You can use http://electric-sql.com to sync into PGlite in the browser from postgres. There are docs here: https://pglite.dev/docs/sync
Embeddable (into JS et al)
There are projects such as https://github.com/wasmerio/wasmer-java and https://wasmtime.dev/ that extend this embeddability to Java, .net, C, C++, rust, Python, Ruby and Go. Wouldn't want to call those 'JS et al'.
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.
We have a long on running research project with the intention of carting a "libpglite" with a C FFI and compiled as a dynamic library for native embedding. We're making steady progress towards it.
Is there a PGlite but like SQlite (so without a running a server), just with the PG flavor of SQL instead of Sqlite's?
I tried to use this when I was building a project about peer-to-peer database sharing in the browser using WebAssembly and WebRTC, but I found it a bit heavy so I used SQLite instead.
Here's the project if anyone is interested: https://github.com/adhamsalama/sqlite-wasm-webrtc
ccc
Everyone is trying to copy DuckDB at this point
Duck db copied from the sqlite
Aaand sqlite uses postgres as reference ”what would psqgl do?” I think it is better hate them all.