Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postgres WASM

supabase.com

Post reply on HN
Print view View original

41–50 of 190 posts

Re: Postgres WASM

#41

Post by ASalazarMX »

bearjaws wrote: post #9

The use cases here are going to be really wide spread in my opinion, just a few ideas off the cuff. Obviously the 30mb size means it won't really be for regular consumer apps, but for enterprise or specific tasks it can make a lot sense. 1. Training websites 2. Interview challenges involving SQL 3. Client side tooling that loads data into your local machine and displays into a SaaS web app without the SaaS app ever h…

Without seeing the marketing, I think running a full RDBMS inside your browser is not a great idea. Just idling it becomes my most CPU intensive Firefox tab, out of dozens, according to about:performance.

I shudder what performance a full-fledged application would demand. I know some people will embed this on an Electron app, for double the fun.

Re: Postgres WASM

#42

Post by kiwicopple »

mytherin wrote: post #32

Looks really nice, but I'm really curious about what hurdles you encountered in making a native WASM version of Postgres. It seems that both the performance and binary size suffer immensely from the VM running underneath. For example, if I compare to DuckDB-WASM [1] there is an immense difference in load time and query execution speed. Are there future plans at creating a native WASM version of Postgres? Making it ru…

congrats to the DuckDB team for their WASM version. I've been following it from afar and it's very impressive.

> what hurdles you encountered in making a native WASM

I'm sure Mark & Peter can jump in with specifics but mostly it was due to complexity - there it probably can be done it's just that we took the path of least resistance.

> Are there future plans at creating a native WASM version of Postgres

We'd like that. If anyone would like to collaborate with Supabase + Snaplet to create a more "native WASM" version then please reach out

Re: Postgres WASM

#43

Post by nitsky »

burggraf wrote: post #11
nitsky wrote: post #5

This is a really exciting milestone for WASM! Has anyone tried compiling postgres for wasm32-wasi and implementing a wasi-compatible interface for the file system and other OS bits postgres needs? I think that would be a big improvement.

Supabase developer here. I worked on this project with the guys over at Snaplet. One thing we are working on is putting postgres on an alternative filesystem using 9p. There's some really cool work by humphd that creates a filesystem inside IndexedDB[0]. We'd also like to maybe use the browser filesystem component to let you store the database on the host device in a path of your choosing. Not sure if these are possi…

Using IndexedDB, the forthcoming SQLite support in Chrome, or the browser filesystem components all might be good paths. Either way, what do you think about using WASI instead of Linux? I think it would reduce the overhead significantly.

Re: Postgres WASM

#44

Post by burggraf »

kiwicopple wrote: post #42
mytherin wrote: post #32

Looks really nice, but I'm really curious about what hurdles you encountered in making a native WASM version of Postgres. It seems that both the performance and binary size suffer immensely from the VM running underneath. For example, if I compare to DuckDB-WASM [1] there is an immense difference in load time and query execution speed. Are there future plans at creating a native WASM version of Postgres? Making it ru…

congrats to the DuckDB team for their WASM version. I've been following it from afar and it's very impressive. > what hurdles you encountered in making a native WASM I'm sure Mark & Peter can jump in with specifics but mostly it was due to complexity - there it probably can be done it's just that we took the path of least resistance. > Are there future plans at creating a native WASM version of Postgres We'd like tha…

Supabase developer here. Yes we'd love to collaborate on a native WASM version. I tried this first before starting on this project and I didn't get very far. I'll have to go back to my tests on that, but it seemed like WASM wasn't yet capable of compiling Postgres due do some libraries not being supported. Hopefully we can find workarounds or push WASM into a new era of compatibility :)

Re: Postgres WASM

#45

Post by kiwicopple »

alex_duf wrote: post #27
bearjaws wrote: post #9

The use cases here are going to be really wide spread in my opinion, just a few ideas off the cuff. Obviously the 30mb size means it won't really be for regular consumer apps, but for enterprise or specific tasks it can make a lot sense. 1. Training websites 2. Interview challenges involving SQL 3. Client side tooling that loads data into your local machine and displays into a SaaS web app without the SaaS app ever h…

I can really appreciate the fun and technical challenge of running postgres in a browser. However the use cases are extremely far fetched. 1. training website: you can use a hosted PG, or use a sqlite wasm 2. same as above 3. if the use case is being offline, then the web browser isn't very relevant. If the use case is to avoid a load on the server, the sqlite in wasm will be just fine. It's only if you go into trigg…

> training website: you can use a hosted PG, or use a sqlite wasm

from a supabase POV (which is in the business of hosting Postgres databases), we will definitely be using this for training/tutorials. We have several thousand visitors to our docs every day, and hosting a database for every one of them is expensive.

We can now provide a fresh database for every user, and they can "save/restore" it with the click of a button is huge.

> use case is being offline

The offline use-case is definitely far-fetched in the current iteration. but that's the beauty of technology - something that seems impossible today can be mainstream in a decade.

Re: Postgres WASM

#46

Post by pistoriusp »

mytherin wrote: post #32

Looks really nice, but I'm really curious about what hurdles you encountered in making a native WASM version of Postgres. It seems that both the performance and binary size suffer immensely from the VM running underneath. For example, if I compare to DuckDB-WASM [1] there is an immense difference in load time and query execution speed. Are there future plans at creating a native WASM version of Postgres? Making it ru…

Snaplet person here: Having a native WASM version would be a huge win for everyone, especially is storage is decoupled from compute!

At the moment the CPU and memory snapshot of the VM (with Postgres) is 12 MB, and subsequent reloads are cached. So yeah, not the worst, but not great.

An optimization is that we're using 9P filesystem. So accessing anything on disk is lazily loaded over the network.

> Are there future plans at creating a native WASM version of Postgres?

Yup! I think that should be the goal, and we (Supabase & Snaplet) would be very happy to work with anyone that wants to build towards that.

Re: Postgres WASM

#47

Post by burggraf »

alex_duf wrote: post #29
burggraf wrote: post #13

Earlier quoted context omitted.

Supabase developer here. I've used this to move data from a live Supabase database down to the browser for testing and playing around with things in a "sandbox" environment. Then I save snapshots along the way in case I mess things up. To move a table over from my Supabase-hosted postgres instance to the browser, I just exit out of psql and run something like this: pg_dump --clean --if-exists --quote-all-identifiers…

Correct me if I'm wrong, but given your profile (I assume someone in the tech world), nothing stopping you from doing all of the above with a local pg. If installing is annoying you could run it in docker.

You're absolutely right, you can use a local pg. This just makes it easier for me, as it's sort of a "sandbox" environment and I can easily take snapshots to do A/B testing or roll things back. I can also send a snapshot to a coworker so they can get my entire environment with all my data in a few seconds.

Re: Postgres WASM

#48

Post by kiwicopple »

member_mini wrote: post #35
pier25 wrote: post #20

Earlier quoted context omitted.

> Supabase will be Meteor in no time. As in they will crash and burn?

Nah I think Supabase will do well. Meteor also did well all things considered. My point is really that they are revisiting all the same technology and product decisions and coming to the same conclusions. There's only one way to architect a PaaS. Next.js and Vercel's offerings are, essentially, also the same. The real risk is having one person build it all. They have a team but not really. Personally I believe that's…

> The real risk is having one person build it all

> having to pretend to have a team

In case you're talking specifically about supabase here, we're a full team: https://supabase.com/humans.txt

Re: Postgres WASM

#49

Post by pistoriusp »

netcraft wrote: post #38

I don't mean to take anything away from this post - its quite amazing and I can't wait to play with it more - but wanted to mention that there are sites out there that I believe solve the training portion maybe a little bit better, at least if all you want is to train on SQL not DBA type actions. My favorite is https://dbfiddle.uk/ - the ability to link and fork a set of statements is extremely handy.

Totally, and what we're really trying to achieve here is to make this available to everyone, so that we can improve it as a collective.

If you're building a product on Postgres and you want expose an evaluation version, or teach someone a Postgres functionality then build on top of this.

Re: Postgres WASM

#50

Post by jcuenod »

Hint: Don't use ctrl-w in their terminal. Turns out that has another meaning in Firefox...

[EDIT]: I'm zero for three thus far. I give up.

Post reply on HN