> 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!

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.

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?

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.

CREATE ROLE dumbo WITH LOGIN PASSWORD 'fuck';

CREATE DATABASE dumbo OWNER dumbo;

It's that easy.

That's like complaining you need to break eggs when you want to make an omelette.

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.)

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     |
    +-----+----------+

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.

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.

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.

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.

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

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.