[UNO WASM + SQLite] Known limitations

[DierkDroth]

I figured I compiled a (subjective and incomplete) list of limitations I came across while researching the subject. Not sure if this is the right place, but anyway...

Current status:

• UNO + SQLite + WASM is based on uno.sqlite-wasm where data is stored to the browser's IndexedDB.
• this is not the approach which SQLite itself will take with the upcoming WASM native support which still would come with significant limitations
• limitations below are not imposed by UNO, but are limitations of the underlying SQLite + WASM technology

Limitations:

• the DB would be deleted if the user 'cleared the browser cache'. I don't have exact details yet, but will add them as I progress. Obviously this carrys a high risk that users delete their whole dataset inadvertently
• even worse, e.g. Safari deletes the IndexedDB after 7 days of inactivity - unless this would be a 'Web app in home screen' (not sure yet what that means, PWA...)
• IndexedDB has no direct reference to a file in the file system (browser dependent). This makes it close to impossible to come up with a solid backup and recovery strategy for 'shit hits the fan' scenarios
• browsers have quotas which are not always transparent (e.g. Chrome) and might result in bad user experience
• SQLite WASM (as well as the whole UNO WASM app) is truely single threaded (I'm purposely leaving aside this for now). This could result in different app behavior (it actually does in my app). Also, DB interaction (synchronous!) blocks the UI thread and could result in undesired user experience (not issue so far in my app).
• IndexedDB performance - for Chrome in particular - is not optimal. At this point I have no 'real world' experience (yet) and would not (yet) know if this negatively impacts SQLite's performance

Further readings:

• IndexedDB with Safari/Webkit
• OPFS support with emscripten