111–118 of 118 posts
When I heard embedded postgres and sync, I immediately thought of pg's logical replication. ElectricSQL looks cool, but any chance of pg's native logical replication working with this?
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.
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 Fir…
Earlier quoted context omitted.
for CI you can already use postgresql with "eat-my-data" library ? I don't know if there's more official image , but in my company we're using https://github.com/allan-simon/postgres-eatmydata
You can just set fsync=off if you don't want to flush to disk and are ok with corruption in case of a OS/hw level crash.
PGlite is fantastic. I use it for my in-browser PostgreSQL server for development. It implements the PG protocol on the server; when clients connect, we forward queries to the user's browser, which runs PGlite under the hood. The result is a PG server that fully lives in your browser: https://dbfor.dev
PGlite is fantastic. I use it for my in-browser PostgreSQL server for development. It implements the PG protocol on the server; when clients connect, we forward queries to the user's browser, which runs PGlite under the hood. The result is a PG server that fully lives in your browser: https://dbfor.dev
how is this different from pglite itself? pglite also runs in the browser
The hard work is done by PGlite and we use PGlite, it just enables PGlite to be accessible from everywhere.
Earlier quoted context omitted.
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…
I've built some pretty intensive stuff in indexeddb and it was the only thing I've ever done, using native browser features, that I could get to consistently crash the browsers I tested it on (granted, this was many years ago). On top of that, the API is so ugly. I cannot believe indexeddb won over websql (when every browser ever already embeds sqlite). What a shame.
Earlier quoted context omitted.
I've built some pretty intensive stuff in indexeddb and it was the only thing I've ever done, using native browser features, that I could get to consistently crash the browsers I tested it on (granted, this was many years ago). On top of that, the API is so ugly. I cannot believe indexeddb won over websql (when every browser ever already embeds sqlite). What a shame.
I wonder if those issues are resolved by using the Dexie.js wrapper, because I've had no problems with that.