Reasons not to use OPFSCoopSyncVFS ?

[mzealey]

I note in #85 @rhashimoto says "If I were forced to choose only one VFS for all browser applications, I would first grumble a lot and then grudgingly choose IDBBatchAtomicVFS". However this was quite some time ago and so given the downsides (size, performance, limited browser compatibility) of the async wasm builds I wonder if this would now change?

The reason I'm asking is because I'm looking at migrating from the official sqlite wasm package over to this one. My website has quite a large install base using sqlite-wasm so the jspi build is out of the question, and the async build goes very slowly. So for me sync wasm and hence OPFSCoopSyncVFS seems a very good combination. In my testing:

• This combo is a bit quicker than the official sqlite wasm build+OPFS vfs (typically 1.1-4x speedup depending on query type)
• Firefox is usable again - on sqlite-wasm performance was about 10* slower than chrome. Now it's about the same
• the js/wasm comes in at half the size (700kb vs 1.2mb)
• wa-sqlite is more compatible with modern build chains (vite)
• No need for COOP/COEP
• The code & docs for this project are much nicer

So, I'm looking for reasons not to switch to using the sync + OPFSCoopSyncVFS version compared to other VFS or compared to the official sqlite-wasm build (eg worse browser compatibility, known corruption or other unreliability, ...)

[rhashimoto]

I note in #85 @rhashimoto says "If I were forced to choose only one VFS for all browser applications, I would first grumble a lot and then grudgingly choose IDBBatchAtomicVFS". However this was quite some time ago and so given the downsides (size, performance, limited browser compatibility) of the async wasm builds I wonder if this would now change?

No, I would still say that for the same reasons. But note that the point of that entire message is that there doesn't appear to be a VFS approach that is optimal for all use cases, and so developers should pick, modify, or write a VFS that meets the needs of their application.

So, I'm looking for reasons not to switch to using the sync + OPFSCoopSyncVFS version compared to other VFS or compared to the official sqlite-wasm build (eg worse browser compatibility, known corruption or other unreliability, ...)

• The official SQLite WASM library is backed by the SQLite project. It likely has quite a few more users, and so likely more opportunities to find and resolve bugs. It will likely have more organized continuity on the loss of a developer.
• OPFSCoopSyncVFS doesn't support transactions involving multiple databases.
• OPFSCoopSyncVFS is slower under contention.

There currently aren't any known issues in OPFSCoopSyncVFS. It is an out-of-the-box sort of solution, and I don't know how well exercised it has been in the real world. I am keeping my eye on this PowerSync thread that might or might not indicate a VFS bug. UPDATE: This has been resolved and appears not to have been a problem with OPFSCoopSyncVFS.

Finally, let me make sure you know this:

Also please note that while I do strive to write production-quality code and I don't object to anyone using it in production (and they do), exploring database persistence strategies has always been the primary purpose of this project. I don't consider it a production library, and I make no commitment to solving your production issues with it.

I have a decent record of finding and fixing bugs, but past performance is no guarantee of future results. 😀

[rhashimoto]

There's one little gotcha with OPFSCoopSyncVFS that I'll record here. OPFSCoopSyncVFS is filesystem transparent, which means that the database file in OPFS is a regular SQLite file that can be opened by any other SQLite program, BUT...

...If you want to open the database where it is (instead of exporting it somewhere else) - say you decide to use OPFSAdaptiveVFS instead - this will likely fail with SQLITE_CANTOPEN. The reason is that OPFSAdaptiveVFS creates some additional files in the same directory and one of them will prevent a successful open by another VFS. You can fix this by removing the file with "-wal" appended to your database filename, e.g. if your database filename is "my.db" under the root OPFS directory:

await navigator.storage.getDirectory().then(d => d.removeEntry('my.db-wal'));

[sgbeal]

It will likely have more organized continuity on the loss of a developer.

Ha! As the Berliners say: "hope is the last thing to die!" 😜

past performance is no guarantee of future results.

It is my sincere hope to have the presence of mind to recall that quote the next time it's relevant.