Learn Postgres at the Playground – Postgres compiled to WASM running in browser
crunchydata.com
crunchydata.com
The post explains a lot of the high level, but we're going to being doing some deeper dives as well including the build process, but also some of how the tutorials are powered by an internal notion doc which allows us to easily iterate and collaborate on the tutorials themselves.
Perhaps our favorite easter egg is that you can bring your own SQL into it for example: https://www.crunchydata.com/developers/playground?sql=https:...
That is super awesome! I plan to use it to allow people to peruse our table structure easily.
Great job!
Any ideas?
https://www.guidingtech.com/fix-google-chrome-out-of-memory-...
Do you provide 3rd party hosting? Might consider replacing ours to something more flexible like yours in the future.
This is very cool but I wouldn't call it an easter egg, I'd just call it a feature!
It's also an amazing demonstration of the power of WASM, I am utterly convinced that DBs running in browser via WASM on top of the "coming soon" filesystem/block store api [0] will be the future of all offline first apps. I think it's going to be SQLite that really sines here (it will be a smaller package), but if you can run Postgres in browser, you potentially have a close alignment between your server and browser implementations.
I love the idea of running Django in browser via PyScript with Postgres!
0: https://developer.mozilla.org/en-US/docs/Web/API/FileSystem - This API doesn't grant access to the users file system, but a local virtual one just for the website. It will operate at the block level so can be used to provide efficient persistent storage for WASM DBs.
—
Edit rather than replying individually:
It’s so important when teaching people a new thing, like sql, to hit the ground running. A lot of these people will have no experience with Docker, package managers or compiling from source. It’s so important to make technology accessible to all. This does that! Imagine high school kids having a lesson on SQL and running Postgres’s just by opening a webpage!
We shouldn’t assume that someone learning Postgres, or just SQL via it, is a developer with experience of other areas of development or system administration.
for tutorial level usage, "apt-get install postgresql-X" or installing Postgres.app has always worked perfectly. what sort of troubles do you run into?
So here I am trying to take the next step and learn SQL along with good database design, but learning these things through Postgres is really not appropriate for someone like me. I think I have to swallow my pride and start with Access or something.
You just download binary for your OS, create a db as described here (https://www.sqlite.org/quickstart.html) and then connect to it with dbeaver.
This is more the enough to get familiar with SQL.
I was in an industry with an absurd number of boilerplate forms that needed to be printed and the ability to create Access forms that automated all the manual filling out coworkers were doing felt like magic. Postgres doesn't really have an equivalent of that.
I know this much about frontend development too but I was sure that you still need a package manager to install your npm\yarn and other tools.
PS: Obviously you can live without one. Regardless of being backend\frontend developer.
PPS: and honestly, how can you be scared of postgresql and co. after webpack? If you can actually understand this crap postgres setup should be to easy for you.
You can figure almost anything out if you spend enough time reading documentation and noodling with it. I'd still rather spend that time solving my actual problem.
Really the key thing here is that learning new things is hard, and anything that can be done to remove potential roadblocks is worthwhile. I've talked to so many people who were put off learning Python because they couldn't get to a working development environment on their own.
So yeah, installing is easy and on a clean install it runs fine but it's not unusual to get pretty annoying issues over time in my experience.
This isn't impossible - I can do it if I consult my notes - but it has enough steps where something might go wrong that it's a pretty high friction process for newcomers.
That's like complaining you need to break eggs when you want to make an omelette.
But - why are the steps needed to create a database and setup credentials such a complex, manual process anyway? Why can't all those steps just be automated by a helper script that ships with postgres?
I reach for sqlite whenever I introduce SQL to people because its so much easier to get started with sqlite.
sqlite> .mode table
sqlite> select * from example;
+-----+----------+
| id | foo |
+-----+----------+
| 123 | afsd |
+-----+----------+
SQLite also has CSV, JSON, HTML and markdown modes - which is pretty neat!I have a friend who we discovered didn't like cooking eggs because picking the shells out of the bowl was tedious. Turns out he was never taught how to crack an egg so he would just throw it in the bowl and have bits of shell everywhere. Point is that breaking eggs may not be so easy for everyone. (Of course, after describing to him how eggs are properly cracked, he was excited to try it out.)
CREATE ROLE dumbo WITH LOGIN PASSWORD 'fuck';
CREATE DATABASE dumbo OWNER dumbo;
It's that easy.
Mine logs in as `postgres`, creates the database and extensions I normally use, then creates a user and grants the appropriate privileges to that application user for the relevant db/schemas. Incidentally, it's the same script I use for "prod" deployments on my homelab.
This is a 15 minute job with coffee break while it compiles. And I don't even remember the whole thing by heart; I have to consult the docs.
The other API worth knowing about is the more direct File System Access API, which is the one that allows direct access now: https://developer.mozilla.org/en-US/docs/Web/API/File_System...
wrt SQLite, icmyi: https://github.com/jlongster/absurd-sql
> on top of the "coming soon" filesystem/block store api
I’m completely unimpressed by Origin Private File Systems, which I believe is what you’re talking about: it’s just a key-value store, just made to look a little like a file system, but is probably exactly equivalent to IndexedDB in capability and usefulness, quite easily perfectly polyfillable atop it. It is certainly completely unsuitable for building a database on top of as far as ACID transactions or such are concerned—you’ll get appalling write performance because you will have to close the file to commit each write.
I wrote more about this in the thread about Safari having implemented OPFS five months ago: https://news.ycombinator.com/item?id=30394737. (My use of “probably” above is explained in there too.)
I’m sure there are rough edges right now, but I’m complete convinced that even if the api isn’t there yet, this use case will win out and we will see it happen.
From memory the teams working on WASM SQLite are working with the File System API working group to ensure their use case is supported.
Heh, didn’t notice the username match there!
I don’t think “rough edges” is the right characterisation. What OPFS provides is just nothing in the direction required. The kind of file system you need to build a database on is a fundamentally completely different beast, with only unimportant surface-level similarities. It would generally require a complete replacement of the backend, with quite possibly literally no code in common.
I’d like something like this, because it’s certainly genuinely useful for cases like this, but I’d honestly be surprised if it ever happens, because it’s just… not webby. To be useful, it just about requires that the whole thing be backed by an actual file system and exposing that, which is something that has been assiduously avoided so far in the design, probably in significant part because it discloses quite a lot about the host system (fingerprinting; disk performance characteristics, quite possibly even file system identification by various nuances in behaviour; and surprisingly large side-channel attack possibilities, mildly similar to the fuss over high-resolution timers), but also because it tends to be a security hazard, just another moving part where things can go wrong more easily than you imagine.
I strongly suspect it will end up a bit like Web SQL: a nice idea that pretty much everyone agrees is a nice idea, but which is also a non-starter for other reasons.
But I wouldn’t mind being wrong. I do want to be able to deploy a robust, high-performing SQLite in the browser.
> The origin private file system provides optional access to a special kind of file that is highly optimized for performance, for example, by offering in-place and exclusive write access to a file's content.
https://web.dev/file-system-access/#accessing-files-optimize...
It was originally going to be a separate high-perf "Storage Foundation" API, but that was merged with the File System Access API.
Thank you for correcting me. I am now enthusiastic about OPFS.
...but then the OPFS will be a quite decent fit. We (DuckDB-Wasm) are also looking closely at OPFS.
IMHO the requirement here is not even to get to full ACID.
With OPFS, we will get close enough to IndexedDB on steroids and bypassing the js heap limits through out-of-core operators.
After all, we are still running in a browser.
So I see the value of Wasm-based databases to be a front-facing accelerator, not a substitute for robust storage solutions.
You can run vscode on docker on kubernetes on the browser with gitpod!
More about that project here: https://simonwillison.net/series/datasette-lite/
I just added support for installing additional plugins written in Python this morning: https://simonwillison.net/2022/Aug/17/datasette-lite-plugins...
Full disclosure: I worked on it.
https://github.com/WebAssembly/threads/blob/main/proposals/t...
Well that's embarrassing, looks like one of our underlying APIs hit a rate limit, we're working on a quick fix for it.
Postgres, possibly surprising to many, is very "simple": it has essentially no dependencies other than a few OS system calls (open, read, write files) and some optional dependencies (e.g. libssl). Therefore, it is very portable and "easy" to compile on many environments. This includes new environments or ideas like compiling it to WASM.
But you need to come up with the idea. This is a great one and opens the door to other use cases. I hope this serves to push the mindset that Postgres can also be used in lighter-weight environments where SQLite (another fantastic database, don't get me wrong) is often considered as the only viable choice.
edit: typo
You can actually use WASM to run your own javascript interpreter and people are already doing that to not be dependent on the interpreter that comes with the browser or wasm runtime (outside the browser). If you are going to run node.js in a wasm runtime, that's what you might want to do. Likewise, if you want to offer a browser IDE for a node.js project, you might want to run node.js in a browser and this is probably what you'd be doing rather than passing through the javascript to the browser javascript interpreter, which lacks most of the node.js API. Just easier that way.
Likewise if you want to run some old internet explorer 10 javascript, packaging up on old version of that as wasm might allow you to do that. The hard part of course would be getting your hands on the source code. But MS might help us out here or somebody might implement something compatible. Very much like is being done with flash.
BUT IT'S FREAKING AWESOME!
Seriously, do you ever imagine Oracle or DB2 running in a browser? Crazy, right?Congrats to the team. To me this is one of the great things about the times we are living in - tons of computing horsepower for cheap, open source software, new-ish technology (WASM), and one crazy idea.
Well, at least I know where all my spare time is going to be spent...
FYI, if you're on MacOS, someone has packaged Postgres into a standard "just works" self contained MacOS app. With a GUI & system tray menu to control it. It's so good that I use it instead of a Docker image for PG. All the psql and pg_restore commands are contained in the .app package and can be called from the terminal.
I cannot wait for the novelty of this to wear off, because the wow factor of "do it, but in a brower" should have a worn off long-ass time ago.
Yes, WASM is awesome like that. But we've been messing with stuff like that since enscripten, if not earlier.
Besides, postgres already runs on pretty much everything.
Now that would be an achievement!
Also, Postgres in browser is actually useful.
Take a look at this project: https://webvm.io/ - explained here: https://leaningtech.com/webvm-server-less-x86-virtual-machin...
I guess for that one would need to implement all Linux syscalls in WASM
This is not the first time someone has gotten PG running in a browser though. Here's another approach:
I want the whole stack to be WASM.
It would provide a lot of interesting advantages for deployment.
Just like the JVM, WASM being relatively limited allows you to assume more about the program you are deploying.
When I see 'in the browser' I read 'in an easy build and ship app'.
https://www.crunchydata.com/developers/playground/basics-of-...
I've been having my kids go through it. They are learning a lot. I would recommend this site to anyone who needs to start with SQL from the ground-up and get a reasonable understanding of the language with practical hands-on usage.
A good first step before jumping into CrunchyData?
We spend some time getting the node-postgres library working with websockets so we could go browser->websockify->postgres: https://github.com/bitdotioinc/node-postgres - this lets us use a full-featured postgres client (with, eg, cursor support) in the browser.
Ideally something that goes from installation from the official deb repositories to a knowledgeable (junior?) dba.
Can WASI use memory as a virtual filesystem?
See this article, where the mention (and link to) polyfill on browsers: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
It's also possible (on Google Chrome) to use browser API's to directly access your host computer's filesystem (see https://developer.mozilla.org/en-US/docs/Web/API/File_System...).
> Due to browser sandboxing there is no way to connect directly to the Postgres instance beyond the embedded psql interface that we establish for you. The current configuration allocates 512MB of memory for your Postgres instance, we may make this more configurable in the future. It’s in the browser, hence if you refresh you’re going to get a fresh instance, we haven’t created any persistence layers (yet).
I'm creating tutorials where I try to let people learn as much as possible without the need to install anything and software in that spirit always makes me happy.
I'm partial to MS SQL Server myself.
So many rave about Postgre. Isn't it just another RDBMS?
Basically PostgreSQL is to databases as Linux is to an OS.
Is it really a circular relationship if the starting premise is "people use it because it's good"?
Hot standby (streaming replication) was a key feature to arrive around then. Also, I'd like to think a lot of the work Heroku did to engineer Heroku Postgres, and market it, contributed much better Postgres support in web frameworks and their affiliated ORMs in those critical years from 2010-2014, where encountering headwinds in defects in Postgres support for Rails, Node, etc was common.
When RDS came around with their Postgres offering, I'd say at that point, it could be said that Postgres entered a new stage: it was no longer reflexive for engineers to shrug their shoulders at shaky Postgres support in drivers/ORMs/etc like they did before that.
Those familiar with the internals might say a lot more about how it's faster or something. IDK, wouldn't surprise me if it were.