postgres-wasm VS mod_wasm

I used https://wasm.supabase.com/ to make sure some SQL commands I was writing for a blog were correct.

I miss a feature where I can share a link with some data/schema pre-seeded (maybe from a gist?)

We achieve this by mounting a compressed 9P filesystem in the VM. 9P provides a Python script which takes a filesystem folder,renames every file an 8-character name and produces a filesystem.json file representing a nested structure with files, original file names, sizes, etc.

maybe https://wasm.supabase.com tech?

Hey HN, we’re excited about this launch. This was a collaborative effort with the team at Snaplet [0].

postgres-wasm is an embeddable Linux VM with Postgres installed, which runs inside a browser. It provides some neat features: persisting state to browser, restoring from pg_dump, logical replication from a remote database, etc.

The idea was inspired by CrunchyData’s HN post about a month ago [1]. We love the possibilities of Postgres+WASM, and so Supabase & Snaplet teamed up to create an open source version. The linked blog post explains the technical difficulties we encountered, and the architecture decisions we made.

We’re still working hard on this, but it’s at a good “MVP” stage where you can run it yourself. Snaplet are working on a feature where you can drag-and-drop a snapshot into your browser to restore the state from any backup. Supabase are exploring ways we can run the entire Supabase stack inside the browser. You can find the Snaplet repo here [2], and the Supabase fork here [3]. There’s very little difference between these two, we just have a different browser UI.

Both Supabase team and the Snaplet team will be in here commenting if you want to know anything else about the technical details.

[0] Snaplet: [https://www.snaplet.dev/](https://www.snaplet.dev/)

[1] Crunchy post: [https://news.ycombinator.com/item?id=32498435](https://news....

[2] Snaplet repo: [https://github.com/snaplet/postgres-wasm](https://github.com...

[3] Supabase fork: [https://github.com/supabase-community/postgres-wasm](https:/...

Hey Tim, I appreciate your willingness to engage. What I'm getting at is a bit more pointed. In terms of composability, Docker and WASM are opposites: Docker requires a stand-alone runtime, and an orchestration layer, etc., whereas a WASM module & runtime can be embedded directly into my application, into a browser, or into (comparatively) simple, time-tested tools like Apache[0].

So, to your point, the opportunity here is to provide WASM-native alternatives to existing container-specific technologies, that are more composable by design, because they don't have to deal with the complexity of trying to ape an extra operating system just to run some software.

For example, I'd love to see container orchestration be supplanted by something like a la carte Erlang-style service discovery—that's a primitive that could easily be composed with other primitives, and wouldn't result in the combinatorial explosion of nouns we see in systems like k8s / Swarm / others.

[0] https://github.com/vmware-labs/mod_wasm