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