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

81–90 of 190 posts

Re: Postgres WASM

#81

Post by Bedon292 »

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…

It is awesome to be able to do things isolated client side and not have to deal with permissions and resources for something like a training website. Which is all stuff you would have to deal with for a hosted version.

And there are plenty of reasons why you may want to use PG over sqlite. Especially if you are trying to mimic a production environment which is PG. Personally I only ever use PG, and never have a reason to use sqlite.

Re: Postgres WASM

#82

Post by lights0123 »

rjh29 wrote: post #78
simcop2387 wrote: post #69

Earlier quoted context omitted.

Chrome supports a USB api that could potentially work for that, https://developer.chrome.com/docs/extensions/reference/usb/ sadly though it's chrome only, not a standard of any kind (no other browsers support it that I know of). ESPHome can use it to program microcontrollers (along with the serial port support).

> This API is part of the deprecated Chrome Apps platform. Learn more about migrating your app. Classic Google...

That's the old one. https://web.dev/usb/ is the supported one.

Re: Postgres WASM

#83

Post by michaelmior »

xani_ wrote: post #57

Huh, thought for a second that was a WASM support for stored procedures or something and was excited for a second

This was also what I was expecting. Another reply to your comment mentioned Wasmer, which I found after a quick Google search. Unfortunately it looks like the last commit was almost 2 years ago and there's an issue where people are inquiring about the status of the project that hasn't seen a reply from the maintainers in about the same amount of time.

Re: Postgres WASM

#84

Post by burggraf »

MuffinFlavored wrote: post #67
angelmm wrote: post #21

One of the things I love from this post is the collaboration on this kind of OSS projects. Making Postgres Wasm helped: - v86[0] to find a new bug - Providing a great deep-dive article that will trigger new ideas in the future - Showcase the possibilities of Wasm and how you can overcome the current challenges I really appreciate these projects are OSS :) Congratulations for the project! [0] https://github.com/copy/v…

Could I hypothetically pass USB through to v86? Like libusb on the host into v86 on the guest? Or do USB over IP or something?

I'm curious -- what's the intended use case for this? This is something we could try to add if gives some cool new functionality.

Re: Postgres WASM

#85

Post by fcoury »

Interesting. I have written a translation layer for the MongoDB wire protocol [0] that persists to PostgreSQL. I am wondering if I could make this layer also compile to wasm and run in the browser.

---

[0] http://oxidedb.com

Re: Postgres WASM

#86

Post by r3tr0 »

burggraf wrote: post #75
r3tr0 wrote: post #63

Earlier quoted context omitted.

what is the best way to contact you.

You can email me at mark @ supabase dot io. (Yeah, I know there are probably robots that can parse that as valid email address, but I'm old-school :))

got it.

Re: Postgres WASM

#87

Post by burggraf »

fcoury wrote: post #85

Interesting. I have written a translation layer for the MongoDB wire protocol [0] that persists to PostgreSQL. I am wondering if I could make this layer also compile to wasm and run in the browser. --- [0] http://oxidedb.com

Wow, this is awesome! So as I understand it, this uses Postgres and JSON fields to emulate the features of MongoDB, sort of as an abstraction?

Re: Postgres WASM

#88

Post by tmpz22 »

member_mini wrote: post #17
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…

> 3. Client side tooling that loads data into your local machine and displays into a SaaS web app without the SaaS app ever having your data Member mini mongo? Supabase will be Meteor in no time.

As someone who (unfortunately) used Meteor in the past I disagree. IMO from a dev perspective Meteor was just a poorly implemented promise at 0-effort real-time functionality on top of a database you were at the time (~2015) already interested in or using. It compounded all the problems of MongoDB with a non-perfect abstraction and javascript framework.

Whatever Postgres in WASM ends up being used for there's no way it repeats all those circumstances - at minimum Postgres is just a more appropriate tool then MongoDB circa 2015.

Re: Postgres WASM

#89

Post by agustinbena »

I can not still agree to the usefulness to run this in a WebBrowser at 30MB. But for running in the backend over a wasm runtime, seems that the use case that make sense for the moment.

Re: Postgres WASM

#90

Post by pistoriusp »

chrisjc wrote: post #64
pistoriusp wrote: post #46

Earlier quoted context omitted.

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…

> especially is storage is decoupled from compute! This would be amazing! I can imagine a situation where external tables are managed by some MPP, and a WASM compute engine (Postgres, DuckDB, etc) would be able to at least read subsets/partitions of the full external table. I wonder if the work required to make a native WASM Postgres would have to be split up into efforts for row-based vs column-based. Selfishly, I w…

We actually kinda see parts of this in https://github.com/superfly/litefs, albeit for SQLite.

And here we see some ideas forming around "pluggable storage for PostgresQL": https://wiki.postgresql.org/wiki/Future_of_storage#Pluggable...

Seriously! If any of this sounds interesting to build, reach out, and we'll make it happen!

Post reply on HN