[HN Gopher] Show HN: PGlite - in-browser WASM Postgres with pgve...
___________________________________________________________________
Show HN: PGlite - in-browser WASM Postgres with pgvector and live
sync
Hey, Sam and the team from ElectricSQL here. PGlite is a WASM
Postgres build packaged into a TypeScript/JavaScript client
library, that enables you to run Postgres in the browser, Node.js
and Bun, with no need to install any other dependencies. It's 3mb
Gzipped, now has support for many Postgres extensions, including
pgvector, and it has a reactive "live query" API. It's also fast,
with CRUD style queries executing in under 0.3 ms, and larger,
multi-row select queries occurring within a fraction of a single
frame. PGlite started as an experimental project we shared on X,
and the response to it was incredible, encouraging us to see how
far we could take it. Since then we have been working to get it to
a point where people can use it to build real things. We are
incredibly excited as today, with the release of v0.2, the Supabase
team has released the amazing http://postgres.new site built on top
of it. Working with them to deliver both PGlite and postgres.new
has been a joy. - https://pglite.dev - PGlite website -
https://github.com/electric-sql/pglite - GitHub repo -
https://pglite.dev/docs - Docs on how to use PGlite -
https://pglite.dev/extensions - Extensions catalog -
https://pglite.dev/benchmarks - Early micro-benchmarks -
https://pglite.dev/repl - An online REPL so that you can try it in
the browser We would love you to try it out, and we will be around
to answer any questions.
Author : samwillis
Score : 342 points
Date : 2024-08-12 14:20 UTC (8 hours ago)
(HTM) web link (pglite.dev)
(TXT) w3m dump (pglite.dev)
| sgbeal wrote:
| To keep the next person from having to look (or ask without
| looking): it supports browser-side persistence via IndexedDB and
| OPFS: <https://pglite.dev/docs/filesystems>
| samwillis wrote:
| Yours and Roys work on WASM SQLite VFSs has directly influenced
| my work on this. Thank you!
| sgbeal wrote:
| > Yours and Roys work on ...
|
| ( _blush_ ) But to be 100% clear: the AHP-based VFS in the
| SQLite project is a direct port of Roy's, so all of the
| credit for that one truly goes to him!
| creativedg wrote:
| Huge fan of PGlite.
|
| It's the perfect solution to have Postgres without the need of
| Docker. With just `npm install`, you can have a Postgres instance
| on your computer. So, it's extremely easy to onboard a new
| developer in your team.
|
| And, the good news, PGlite works perfectly with Next.js.
|
| I'm using PGlite in local and development environment with
| Next.js Boilerplate: https://github.com/ixartz/Next-js-
| Boilerplate
|
| With only one command `npm install`, you can have a full-stack
| application, which also includes the database (a working
| Postgres). And, no need to have/install external tools.
| tracker1 wrote:
| Definitely interesting, though I often just use docker compose
| for dev dependencies, this is definitely a cool alternative.
| creativedg wrote:
| Yes, it's very cool alternative and it removes the need for
| docker compose for dev environment.
|
| On top of it, PGlite also perfect for CI and testing.
| ggregoire wrote:
| Wouldn't be easier to have a shared dev database? So that
| each developer doesn't have to apply the migrations and
| import the dumps in their local db, and figure out why the
| local db for dev A is different than the local db for dev
| B.
| andruby wrote:
| That sounds cumbersome when devs are working in their
| respective branches and changing the schema (adding
| migrations)
| motolov wrote:
| IME, creating scaffolding to allow for a known,
| reproducible and clean state (of both DDL and DML) are
| wild systematic (eg across the team and the estate)
| productivity and stability boosts. Not having to be
| "connected to the shared dev DB frees engineers of
| latency (every ms counts) and also of mutulple pollutants
| to that database (eg Sally was writing
| protractor/cypresss tests and now the foo table has 3m
| rows, george was doing data exploration and manually
| entered records to the DB that now causes a runtime
| exception fot the team, etc)
|
| If a shared dev DB is really what everyone wants, then at
| least having the scaffolding mentioned above to fix the
| DB state when pollution happens (it will) will help heal
| foot shots. In industrialized practice, what you are
| mentioning (a shared dev/env) is really the "QA"/pre-prod
| environment. Ideologically and personally (putting on
| down vote helmet) if you can't run the whole stack
| locally you're in for a world of trouble down the road..
| local first, test extensively there, then promote
| changes.
| tracker1 wrote:
| A shared dev database can be okay for application dev.
| Locally deployable database is better imo. By nature of
| migration scripts running for every dev locally, it helps
| to better ensure the stability of said scripts. This
| can/should be combined with snapshot runs that represent
| your production environments.
|
| More critical still if you have more than one
| "production" environment, where in different
| customers/clients may be at different application and db
| versions from one-another. This is often the case for
| large business and govt work. With shared environments
| it's often too easy to have a poorly adapted set of
| migration scripts.
| saurik wrote:
| Does there happen to be a native analog to this? So like, if I
| eventually want some kind of native app, I wouldn't have to throw
| away the architecture entirely and start over? I only see mention
| of the WASM version of this in the website/docs.
| samwillis wrote:
| It's planned.
|
| We want to extract the core changes to Postgres that we had to
| make and create a "libpglite" C lib that can be linked to from
| any language/platform.
|
| Support important for React Native, as it doesn't have WASM
| support.
| nikki93 wrote:
| This would be nice also to have an API that's usable from
| C/C++ code running in Wasm. I see libraries often do this
| where they expose a C/C++ library like Postgres to Wasm and
| the main / documented API is JS and you have to dig a bit to
| find the C/C++ API if it's possible to access it that way.
| simonw wrote:
| I'd seen this running in a browser before (the ~3MB download is
| really impressive for that), but I hadn't clocked that it runs
| server-side with Node.js and Bun as well:
| https://pglite.dev/docs/
|
| Since that's still not spinning up an actual network server, that
| feels like it's an alternative to SQLite - you can spin up a full
| in-process PostgreSQL implementation, that persists to disk, as
| part of an existing Node.js/Bun application.
|
| That's really interesting!
|
| I'd love to use this from Python, via something like
| https://github.com/wasmerio/wasmer-python or
| https://github.com/bytecodealliance/wasmtime-py - has anyone run
| PGlite via one of those wrappers yet?
| samwillis wrote:
| Getting PGlite working with other languages is very high on my
| list. We are working on two approaches:
|
| - a WASI build with a lower level api that users can wrap with
| a higher level api.
|
| - a "libpglite" that can be linked to by any native language.
| The WASI build is likely a WASM build of this.
|
| Most languages already have a Postgres wire protocol
| implementation and so wrapping a low level API that reads/emits
| this is relatively easy - it's what the JS side of PGlite does.
| sitkack wrote:
| I'd love to see this for SQLite and DuckDB at the same time.
| I could see them using a common wasi filesystem shim so they
| can transparently do range requests over http blobs.
|
| Do you have a branch for this work?
| samwillis wrote:
| No branch yet, we're still in the early research and
| experimental stage.
| tracker1 wrote:
| Definitely interesting... maybe someone more familiar with the
| licenses involved can chime in on how this might impact a
| project/solution and compare/contrast to something like
| embedded FirebirdSQL.
|
| For example, can you use this in/with a commercial project
| without releasing source? If you embed this, will you need to
| change your license to match pg/fb?
|
| aside: Mostly asking out of curiosity if anyone knows already,
| if I actually had an immediate need, would be reviewing this of
| my own accord. I often dislike a lot of the simplicity behind
| SQLite in very similar ways as to things I don't care for with
| MySQL/MariaDB.
| abrichr wrote:
| As a workaround, maybe something like this could work:
|
| db.js: const { PGlite } = require('@electric-
| sql/pglite'); const db = new PGlite();
| async function execSQL(sql) { await db.exec(sql);
| return { success: true }; } async function
| querySQL(sql, params) { const ret = await
| db.query(sql, params); return ret.rows; }
| // Command-line interface logic const action =
| process.argv[2]; const sql = process.argv[3];
| const params = process.argv.slice(4); if (action
| === 'exec') { execSQL(sql).then(result => {
| console.log(JSON.stringify(result));
| process.exit(); }); } else if (action ===
| 'query') { querySQL(sql, params).then(result => {
| console.log(JSON.stringify(result));
| process.exit(); }); }
|
| main.py: import subprocess import
| json def execute_sql(sql: str) -> dict:
| result = subprocess.run( ['node', 'db.js',
| 'exec', sql], stdout=subprocess.PIPE,
| text=True ) return
| json.loads(result.stdout) def query_sql(sql: str,
| params: list) -> list: result = subprocess.run(
| ['node', 'db.js', 'query', sql] + params,
| stdout=subprocess.PIPE, text=True )
| return json.loads(result.stdout) # Example Usage
| create_table_sql = """ CREATE TABLE IF NOT EXISTS todo
| ( id SERIAL PRIMARY KEY, task TEXT,
| done BOOLEAN DEFAULT false ); """
| execute_sql(create_table_sql) query_result =
| query_sql("SELECT * FROM todo WHERE id = $1", ["1"])
| print(query_result)
| samwillis wrote:
| We have the (accidentally undocumented) execProtocolRaw api
| that lets you execute Postgres wire protocol messages. If you
| use that you can then use a Python Postgres wire protocol lib
| to get all the type support.
| networked wrote:
| I'd also love to try PGlite in Python.
|
| While reading this thread, I realized that you could already
| access PGlite in Pyodide. Pyodide is a Wasm port of CPython. It
| can work with JavaScript objects through proxies.
|
| Here is a demo. I have run the code in current Node.js 18, Deno
| 1, and Bun 1. import { PGlite } from
| "@electric-sql/pglite"; import { loadPyodide } from
| "pyodide"; globalThis.db = new PGlite(); let
| pyodide = await loadPyodide(); console.log(
| await pyodide.runPythonAsync(` import js
| ret = await js.db.query(""" SELECT 'Hello,
| world!' AS "greeting"; """)
| ret.rows[0].greeting `), );
|
| It works on my machine: > npm init -y >
| npm install '@electric-sql/pglite@==0.2.0' > npm install
| 'pyodide@==0.26.2' > node index.mjs prerun(C-node)
| worker= false Running in main thread, faking
| onCustomMessage Hello, world!
| batmansmk wrote:
| Pretty awesome. Would love to use it in CI and locally for our PG
| product. We use Prisma, so I guess we have to wait for the
| connector that looks like pg to plug it in.
| dboreham wrote:
| Curious, what's the benefit vs running real PG in a container
| for this specific use case?
| creativedg wrote:
| I confirm it works perfectly in CI and locally. I'm using it in
| CI and locally.
|
| Not sure about Prisma but it works with Drizzle ORM.
| samwillis wrote:
| pg-gateway from Supabase does exactly this, you can start a
| PGlite and then connect to it from any standard PG client:
| https://github.com/supabase-community/pg-gateway
| drzaiusx11 wrote:
| Anyone know if something similar is available for MySQL/Maria?
| This is very cool, especially given the tiny size of it
| metadat wrote:
| How did they manage to fit Postgres in 3MB?
| AlexErrant wrote:
| Answered here https://news.ycombinator.com/item?id=41224295
|
| > You might remember an earlier WASM build[1] that was around
| ~30MB. The Electric team [2] have gone one step further and
| created a complete build of Postgres that's under 3MB.
|
| > Their implementation is technically interesting. Postgres is
| normally multi-process - each client connection is handed to a
| child process by the postmaster process. In WASM there's
| limited/no support for process forking and threads.
| Fortunately, Postgres has a relatively unknown built-in "single
| user mode" [3] primarily designed for bootstrapping a new
| database and disaster recovery. Single-user mode only supports
| a minimal cancel REPL, so PGlite adds wire-protocol support
| which enables parametrised queries etc.
| namanyayg wrote:
| How does the performance compare to actual postgres?
| samwillis wrote:
| WASM is inherently slower than native, but it does very well!
|
| We have some micro-benchmarks here that have some baseline
| native numbers to compare to: https://pglite.dev/benchmarks
|
| Much of the complexity with WASM in the browser actually comes
| down to the performance of the underlying VFS for storage. When
| running in-memory or using the OPFS VFSs both PGlite and the
| WASM SQLite builds are very performant, absolutely capable of
| handing the embedded use case.
| jfeiwell wrote:
| Any benchmarks against redis?
| samwillis wrote:
| Redis is a very different database, I'm not sure you could
| do a comparison that was meaningful in any way.
| bezbac wrote:
| I recently experimented with using pglite for API integration
| tests in one of my side projects. It worked pretty well and has
| much better DX than using something like testcontainers[0] to
| spin up postgres running in docker.
|
| [0]: https://testcontainers.com
| riverdroid wrote:
| I would also love to use it this way in Go. Currently we dump
| SQLite compatible schema to use for SQLite powered integration
| tests even though we use postgres when live. It allows us to
| have zero dependency sub-second integration tests using a real
| database. Being able to use postgres would be even better,
| allowing us to test functionality requiring PG specific
| functionality like full text search.
| koeng wrote:
| I do exactly the same thing. I'm even running SQLite in wasm
| so I don't have any C dependencies. Switching out for
| Postgres would be awesome
| FlyingSnake wrote:
| I'm bothering the PGLite team a lot to help us enable this
| :-)
|
| We have different options like embedded-postgres or
| integreSQL, but none match the simplicity of PGLite. I hope
| this wish comes true soon.
|
| https://github.com/fergusstrange/embedded-
| postgres/tree/mast...
|
| https://github.com/allaboutapps/integresql
| koeng wrote:
| What is the problem with
| https://github.com/fergusstrange/embedded-
| postgres/tree/mast... ?
| samwillis wrote:
| I see unit and integration testing as a massive opportunity for
| PGlite. I know of projects (such as Drizzle ORM) that are
| already making good use of it.
|
| The team at Supabase have built pg-gateway
| (https://github.com/supabase-community/pg-gateway) that lets
| you connect to PGlite from any Postgres client. That's
| absolutely a way you could use it for CI.
|
| One thing I would love to explore (or maybe commenting on it
| here will inspire someone else ;-) ) is a copy on write page
| level VFS for PGLite. I could imagine starting and loading a
| PGlite with a dataset and then _instantly forking_ a database
| for each test. Not complexities with devcontainers or using
| Postgres template databases. Sub ms forks of a database for
| each test.
| makkesk8 wrote:
| Awesome work! A killer feature of sqlite that I would love to see
| in pglite would be javascript window functions.
| isoprophlex wrote:
| Huh, can you do that? I can't google anything just now, got a
| link to some docs about js window functions in sqlite?! Sounds
| very powerful
| AlexErrant wrote:
| Maybe they're talking about
| https://www.sqlite.org/appfunc.html where you can define a
| window fn in the (perhaps JS) app via
| `sqlite3_create_window_function()`.
| samwillis wrote:
| This is high on my list, I have a few ideas how to do it,
| one being a "PL/JS" extension that calls out to the host JS
| environment to run JS functions.
| isoprophlex wrote:
| I think PG is relatively ideal for that. In a classical
| data warehousing/ETL context, I've called python directly
| from inside PG, which has its quirks but is pretty
| doable, all in all...
|
| https://www.postgresql.org/docs/current/plpython.html
| teaearlgraycold wrote:
| Heads up, the supabase link on the front page 404s
| samwillis wrote:
| Thanks, fixed!
| AlexErrant wrote:
| Bug report? On https://pglite.dev/repl/ running `SELECT 'a fat
| cat sat on a mat and ate a fat rat'::tsvector @@ 'cat &
| rat'::tsquery;` works, which is cool.
|
| However, running `SELECT to_tsvector('fat cats ate fat rats') @@
| to_tsquery('fat & rat');` fails with `y is not a function`. Then
| trying to run the first query yields `null`, which is weird. I
| can open an issue if you want :)
| kylemathews wrote:
| Posting the issue to GitHub would be great!
| AlexErrant wrote:
| ack
| bearjaws wrote:
| PGlite / ElectricSQL is definitely something I want to use in a
| future job.
|
| The ability to replicate and subscribe to the changes, all within
| the browser seems incredibly powerful.
|
| Having worked on medical software that runs a 2,000,000+ patient
| workload that perform refills for chemotherapy/HIV/immuno drugs,
| where it was common for people to trample each others work as
| they ran insurance, called patients etc...
|
| We had to roll our own locking system that relied on interval
| functions (yay IE7) and websockets... This meant when you called
| the patient, someone running financial assistance would be unable
| to work on the same profile.
|
| I can envision other uses for FTS or even vector search locally,
| since they are insanely expensive at scale.
| TeeWEE wrote:
| That means getting those 2 million patients on every device...
| Really bad choice for medical software.
| thruflo wrote:
| Electric does partial replication. It's specifically a system
| for syncing a different subset of data onto each local
| device.
| isoprophlex wrote:
| That's great! Corpo beancounters want us to move off docker on
| EC2 onto bare metal, making both dev and deploy experience
| terrible. This will help ease pain!
| samstave wrote:
| Weird question: Since you mention 'bare-metal' and this is
| "enables you to run Postgres in the browser"
|
| UH, could you do:
|
| bare_metal --> HeadlessGPU-Chrome --> PGLite with whatever
| orchesrtration and you have a an automatable 'browser' that can
| scrape/store/logic/log/be-config'd from/lookup directly to your
| browserDB
|
| and maybe run a fastAPI ontop of such that you have a full
| stack, baremetal, headless, browserDB/fastAPI/endpoint
| processing doohicky?
|
| Or does this sound dumb?
|
| Because this is exactly what I actually need and am attempting
| to create - but its beyond my capabilities in any
| functional/elegant implementation...
|
| https://www.browserless.io/blog/browserless-gpu-instances
|
| https://github.com/dhamaniasad/HeadlessBrowsers
| samwillis wrote:
| PGlite also runs in Node and Bun, so you can easily run it on
| backend servers. (couldn't fit that in the HN headline)
| samstave wrote:
| Sorry if this is in the RTFM;
|
| So, you can basically use this to deploy a portable fully
| enclosed little webapp.
|
| Basically any little web-app that has a bunch of backend
| DB:
|
| A sales USB drive that loads a page that then has the
| pglite of all your product stuff on there. and you can just
| provide custom buttons to slurp data either way.
|
| Utils to yank a [data] from a postgress server, onto your
| little sneaker-DB-USB -- then carry it over and to a DB
| function...
|
| A little util USB that you already have it setup such that
| you can curl a bunch of data directly into tables on your
| little headless-browser-pglite minion?
|
| Full Kisok DB USB (SSD) upgrades.
|
| Basically - running a pico headless postgress DB with a
| webUI?
|
| --- aside:
|
| samwillis March 2008
|
| samstave March 2009
|
| :-)
|
| ---
|
| WOW:
|
| https://i.imgur.com/6YLwEuj.png
|
| --
|
| Yeah this is pretty dopes.
| samwillis wrote:
| Yep exactly, either in the browser, or using something
| like Electron to package it as a desktop app.
|
| :-)
| isoprophlex wrote:
| It doesn't need so many moving parts imo. I was thinking to
| just grab the npm package and slap a tiny TS interface on top
| of that to mock my bespoke vector db. In the vein of
| https://news.ycombinator.com/item?id=41225080
| cheema33 wrote:
| > Corpo beancounters want us to move off docker on EC2 onto
| bare metal
|
| There is a very good reason for it. EC2 is way way overpriced.
| postalrat wrote:
| And you can't have your own docker on bare metal?
| srameshc wrote:
| If I understand correctly, this is like SQLite, but Postgres. I
| love SQLite, but sometimes I need a little more. So, no more
| saving Date as text and we have arrays, jsonb etc and all the
| good stuff from Postgres. Am I right ?
| samwillis wrote:
| Exactly, all your favourite PG types, plus any that come with
| extensions such as vectors with pgvector.
|
| We are working on PostGIS to, which will bring the geo types to
| PGlite.
| cpursley wrote:
| Woah, this is neat - insane that it can handle extensions.
|
| Just added a new section to my "Postgres Is Enough" gist:
|
| https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f...
| FlyingSnake wrote:
| PGLite is a wonderful achievement and I've a fan of it since it's
| early days.
|
| If they get it to a stage where other languages apart from JS can
| use it, it could be revolutionary. The possibilities are
| limitless.
| revskill wrote:
| The migration docs to integrate with Vite/webpack is still
| lacking though.
| loevborg wrote:
| PGLite is amazing for integration testing of queries against a
| real in-memory db.
|
| Is it possible to use PGLite for that purpose in non-JS
| environments, like e.g. golang?
| samwillis wrote:
| You can use pg-gateway from supabase
| (https://github.com/supabase-community/pg-gateway) to start a
| PGlite and connect form any standard PG client.
|
| Support for other languages is high on my list, the plan is to
| build a "libpglite" as a native C lib and a WASI build that can
| run in any WASM runtime.
| Kinrany wrote:
| Can it run in Node while still persisting data to disk?
| samwillis wrote:
| Yes, we can persistent to the normal filesystem with Node and
| Bun, and to IndexedDB and OPFS in the browser:
| https://pglite.dev/docs/filesystems
| NetOpWibby wrote:
| This is exciting. My database of choice is EdgeDB, which uses
| Postgres under the hood. It's not so far-fetched to imagine
| EdgeDB in the browser now!
| Retr0id wrote:
| Normally I'd say the main difference between postgres and SQLite
| is that the latter is in-process. Now that they can _both_ be in-
| process, is there a more detailed comparison of the two? When
| might I prefer one over the other?
| non- wrote:
| Would really like to see a benchmarking analysis vs SQLite. How
| do they compare on memory usage and overhead?
|
| I already default to SQLite for new side projects with the idea
| that "eventually I'll migrate to Postgres if this project gets
| legs", so switching to PGlite feels like a no-brainer as long as
| it's not going to weigh my apps down or force me to upgrade out
| of whatever entry-level server solution I'm using is for a given
| project.
|
| EDIT: Found the benchmarks here https://pglite.dev/benchmarks
| samwillis wrote:
| Ah, you beat me to it, yes those benchmarks give you a good
| overview of baseline performance. But it'a a little nuanced as
| the underlying VFS performance is very significant.
|
| Both PGlite and SQLite in the browser is incredible. The latter
| is a little lighter weight and more mature, but PGlite brings
| with it all the type support and extensions that you love with
| Postgres. It comes down to what works best for your project.
| satvikpendem wrote:
| Congrats on the Show HN. I follow the ElectricSQL Discord server
| and I was distinctly interested in this but for other languages
| than TypeScript, so it's nice to see that making it language
| independent is high on your list. I also saw that ElectricSQL is
| being rewritten due to architectural changes, does that impact
| PGlite at all or are they separate projects now? What is the
| relationship between PGlite and ElectricSQL as well, just
| curious?
|
| Also, fun etymological thing, SQLite is actually SQL-ite, as in,
| urbanite, not SQ-Lite, but due to rebracketing [0] and libfixing
| [1], now people seem to use the -lite suffix rather than the -ite
| one, presumably because _lite_ actually implies something whereas
| _ite_ would not, as much. It 's like how helicopter is actually
| _helic_ and _opter_ , a helical wing that spins, but now people
| think of it as _heli_ and _copter_ , calling other things related
| to it like helipad, or quadcopter, as Wikipedia states.
|
| [0] https://en.wikipedia.org/wiki/Rebracketing
|
| [1] https://en.wikipedia.org/wiki/Libfix
| samwillis wrote:
| Hey, yes, PGlite and Electric sync are separate projects, but
| we are very much building PGlite as a sync target for Electric.
|
| The changes we are making with Electric is towards a more
| loosely coupled stack, rather than the tightly integrated stack
| we had before. PGlite is one possible client store for Electric
| sync, and fulfils the use case where you want to have a full
| SQL database on the client along with (potentially) the same
| schema on client and server.
|
| The name is (obviously) a nod to SQLite, which goes without
| saying is an incredible database. We went with the small "l" in
| the name to add a slight differentiator and a nod towards
| "light", and we are a light weight Postgres.
| zooq_ai wrote:
| what kind of data load are we talking here? I know it gets
| stored locally. So, is it limited by my local disk size.
|
| How will it perform if I have 1TB of data?
| blueprint wrote:
| Anyone know how this would play with at-rest encryption
| extensions?
| samwillis wrote:
| There are two options here:
|
| - Build a Postgres at-rest encryption extensions as WASM, that
| should "just work" as long as you can build the extension.
|
| - Create an encrypted VFS for PGlite. This is doable now, but
| we haven't yet documents the VFS API as we want to make it a
| little cleaner.
|
| But yes, it's 100% possible to build an at-rest encryption
| scheme for PGlite.
| Cu3PO42 wrote:
| When I saw the headline, I immediately thought "I bet this would
| go really well with ElectricSQL", so it's great to see this
| coming from you!
|
| The immediate DX is incredible and I'm itching to use PGLite (and
| ElectricSQL) in a production project, I expect it would remove
| quite a few pain points I'm currently experiencing. (Also, I just
| like working with CRDTs.)
|
| I don't have any constructive criticism to offer right this
| moment, but I just wanted to congratulate you on the launch and
| an incredible looking product!
| ggregoire wrote:
| I was gonna ask what do people use to sync their local pg with
| their remote pg, but turns out, that's exactly what the authors
| are building. Cool stuff, and gratz on pglite!
| herpdyderp wrote:
| What's the equivalent Postgres version? Meaning, if I wanted to
| make sure my app that is currently using a Postgres Docker image
| is compatible with PGlite before switching, which version of
| Postgres should my Docker image be on?
|
| I see "PostgreSQL 15devel" in a screenshot so I'm assuming that
| means v15 but explicit documentation on current and future
| Postgres version usage would be very nice. For example, how will
| I know when (if) you update to v16?
| samwillis wrote:
| Ah, screen shot is out of date. We are on v16.3.
| herpdyderp wrote:
| Thanks for the quick response! I'd love to see a list of
| PGlite version vs Postgres version somewhere. Regardless
| though, congrats on launch! For small projects where I won't
| care much which Postgres version I'm on, I'll totally give
| this a shot.
| ZitchDog wrote:
| > it has a reactive "live query" API
|
| Very cool! Most of the examples for reactive queries are very
| basic (only single tables). Do live queries support joins /
| aggregations?
| samwillis wrote:
| Yes, they should all work.
|
| We save the query as a view and then introspect it to see what
| tables it depends on. It then uses pg_notify to watch for
| changes.
|
| The plan is to integrate pg_ivm
| (https://github.com/sraoss/pg_ivm) to make it even more
| efficient.
| cheema33 wrote:
| The existing list of extensions is already quite impressive.
| But addition of pg_ivm would really take it to the next
| level.
| sam_perez wrote:
| Oh cool, how would you compare this to DuckDB?
| cheema33 wrote:
| The filesystems page at https://pglite.dev/docs/filesystems says
| the following:
|
| > "We would recommend using the IndexedDB VFS in the browser at
| the current time as the OPFS VFS is not supported by Safari."
|
| Is it possible to configure PGLite to use IndexedDB on Safari and
| OPFS on Chrome & Firefox?
| sabr wrote:
| This is amazing! Will there be something like Litestream/rqlite
| for PGlite?
| ChrisArchitect wrote:
| Related:
|
| Subabase announcement post
|
| _Postgres.new: In-browser Postgres with an AI interface_
|
| https://news.ycombinator.com/item?id=41224286
___________________________________________________________________
(page generated 2024-08-12 23:01 UTC)