Not PG no. At least not yet. I wonder if they can get WASM to work, which seems to be working roughly the same problem from a totally different starting point and perspective. I'm pretty sure PG binaries for WASM do exist though.

I think that you might be talking about pglite.dev when talking about wasm from my understanding, Wasm has a performance hit though from my understanding and unless one plans to run postgres on web.

on the other hand a static cross platform single binary Postgres binary doesn't really have any performance hit.

(anecdotally, Personally I would be interested for something like this existing and maybe even integrating it with golang embed. Some of my apps are full stack golang with sqlite backend all baked into a single static binary which I can run and be cross-compiled but I would like to have the same level of flexibility but with postgres as well hopefully)

Yes, I'm sure the WASM binary for PG has a big perf hit. If you are just using it for testing, it probably doesn't matter?

Why does the perf hit matter to you? Are you trying to run WASM binaries of PG in production? That seems like a terrible idea.

No, I am not running WASM binaries of PG in production given its perf hit but I would like to have the simplicity that I have with sqlite.

My advice: Just use SQLite. Don't use PG if you don't need it. I mean PG is awesome. I use it all the time, but I also use SQLite all the time too.

SQLite is also a replacement for fopen()[0]. if you need to read/write data files, I recommend using SQLite instead. Replace your CSV's with SQLite, etc.

0: https://sqlite.org/whentouse.html

Yup its a really decent advice overall but I feel like there were some few use-cases I think where postgres made more sense but I found the initial setup to be slightly more complex than sqlite and oh I love both sqlite and postgres and was just thinking of merging somewhat all the things that I like about them haha but I get what you mean, both sqlite and postgres are awesome :)