Hybrid OPFS/IndexedDB VFS could be (almost) WAL-like

[rhashimoto]

Here's another random idea. An OPFS VFS, like AccessHandlePoolVFS, could create a mirror of its database file in IndexedDB with the same versioned page scheme that IDBBatchAtomicVFS uses. I wouldn't expect that to be a big drag on performance - maybe negligible - because the writes to IndexedDB would be fire and forget with no waiting (an Asyncify build would not be needed). Then you could use an IndexedDB VFS - perhaps just IDBBatchAtomicVFS patched to be read-only - for as many read-only connections as you wanted.

This wouldn't work transparently to the application - if multiple contexts need to write to the database then they would have to share a connection for write transactions - but it would allow concurrency that is nearly like Write-Ahead Logging (WAL) where database readers can query concurrently with other readers and one writer.

There are a couple reasons this wouldn't be quite as concurrent as WAL:

1. Read access to IndexedDB is likely to be blocked during an IndexedDB write transaction by the mirroring VFS, so reads and writes won't be truly concurrent. However, reads need not be blocked for the duration of an SQL write transaction because a SQL write transaction could be split into multiple IndexedDB write transactions.
2. Opening a new concurrent read transaction after a mirrored write transaction might block until the write transaction completes. I think Chrome did some IndexedDB transaction ordering magic to minimize this (which was unintuitive and surprising for some developers, including me), not sure if that is still the case.

This isn't going to be worthwhile for most applications. One benchmarking attempt indicates that you probably need a fair amount of concurrency to reach the point where concurrent reads from multiple connections beats multiplexing reads on a shared but faster connection. Nevertheless, it is an interesting idea for the right workload, and maybe it could be a jumping-off point for other approaches.