samwillis

Redis is a very different database, I'm not sure you could do a comparison that was meaningful in any way.

No branch yet, we're still in the early research and experimental stage.

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.

Ah, screen shot is out of date. We are on v16.3.

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.

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.

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.

Yep exactly, either in the browser, or using something like Electron to package it as a desktop app.

:-)

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.

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.

Hey Sam from Electric here, I work on PGlite

What the team at Supabase have built with postgres.new is incredible, it has been a lot of fun to work with them last month or so to have PGlite incorporate the things they needed. It's fed directly back into the development, helped us iron out some bugs and finish hitting the feature list required. They are the most genuinely nice team to work with.

SQL databases and LLMs go together so incredible well, the structured data and schema enables an LLM to infer so much context about the database and the underlying data. This exploration into a UI over this pairing is going to be incredibly influential, it opens up what has traditionally been a complex technical problem (designing database schemas) to everyone. That's the true power of LLMs.

I'm not going to go on about PGlite here as postgres.new really deserves the limelight!

PGlite also runs in Node and Bun, so you can easily run it on backend servers. (couldn't fit that in the HN headline)

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

Thanks, fixed!

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.

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

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.

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.

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.

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.

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.

Yours and Roys work on WASM SQLite VFSs has directly influenced my work on this. Thank you!

Hey Sam from Electric here, I work on PGlite

What the team at Supabase have built with postgres.new is incredible, it has been a lot of fun to work with them on it over the last month or so. It's fead directly back into the development of PGlite and helped us iron out some bugs and finish hitting the feature list required.

SQL databases and LLMs go together so incredible well, the structured data and schema enables an LLM to infer so much context about the database and the underlying data. This exploration into a UI over this paring is going to be incredibly influential, it opens up what has traditionally been a complex technical problem to everyone. That's the true power of LLMs.

I'm not going to go on about PGlite here as postgres.new really deserves the limelight!

We (as a family) moved from Spotify to Apple Music, but it was entirely down to cost. As our kids have grown and gained their own devices we've had to find apps/services that we can share with them. The most successful has been Apple One, having Arcade for them, TV and News for us, the storage, and extras like Fitness, it made sense to get Apple One. At that point we had Apple Music for "free" so decided to migrate after over ten years. Genuinely very happy with it!

Many of the complaints in the OP apply to Sonos too though, we brought into it years ago, and are incredible disappointed with the recent changes.

There was a really good post with significant background earlier this year:

> Is the Living Computer Museum Dead?

https://www.pcjs.org/blog/2023/02/16/

https://news.ycombinator.com/item?id=34831880 (238 comments)

> At the time, Vulcan CEO Bill Hilf framed the closure both as an unavoidable consequence of COVID-19 and as a difficult decision that was actually in keeping with Paul Allen’s wishes – that how Paul wanted his money to be spent after he was gone was very different from when he was alive.

> Yet it’s almost impossible to square the idea that Paul Allen, after investing so much time, energy, and money in the Living Computer Museum and its people – not to mention his express hope that efforts like his would not be “lost to time” – would have also left instructions that could somehow be interpreted to justify completely shutting down LCM after his death.

Not really, no more so than a random webpage running js/WASM in a sandbox.

The only output from the WASM is to draw to screen. There is no chance of a RCE, or data exfiltration.

I think it's interesting to observe the development speed of Bun vs Deno when comparing Zig and Rust.

Bun is written in Zig and links to the WebKit's JavaScriptCore.

Deno is written in Rust and links to V8.

It seems to me that the development of Bun is significantly faster than Deno, how much of that is down to the easy of interoperability of Zig and C/C++ vs some of the hoops you have to jump though when using Rust with a C/C++ lib?

(I may be wrong on this an the Bun team are just exceptionally quick)

Things that are important to society will naturally be preserved. I believe in the moral right to be forgotten.

We cannot, and should not, preserve all of knowledge forever.

Don't get me wrong, I love the internet archive, and the team behind it are incredible. As a resource it's very important to maintain and preserve. However, I'm sure that at some point, either due to the economics of it or through hardware failure, the content saved by the AI will begin to be lost. I don't see that as a bad thing.

I quite like the fragility of it, it makes it more apparent that everything is transient. In a way I wish the IA had a half life on content, that it would decay over time, pages and images would be randomly deleted. Little by little it would rot and become nothing, a reflection of humanity.

I suppose that's the internet itself...

Yep, it would be difficult to maintain a consistent radius with that method.

My assumption (I've not looked) is that you could offset the surfaces from the two sides (say A and B), and then calculate the intersection of an offset of A with the original B. Then do the opposite for the other side. I think that will give you two edges that will produce a consistent radius.

Offsetting surfaced and calculating intersections aren't exactly easy problems to solve on their own. Fillets are hard!

(Solvespace is awesome BTW! If I had the time (or the expertise) it also makes a brilliant foundation for all this)