Consider web native database

[ross-weir]

Instead of having many backend database implementations (tauri+sqlite for example) use a web native database (indexdb) that executes everywhere webview is supported.

Examples:

• https://github.com/dexie/Dexie.js

The db load should actually be quite minimal for this app, using indexdb shouldn't be a performance bottleneck.

[ross-weir]

Ensure if this is done its implemented in a way where the database backend can be swapped back to a traditional backend

I have no experience with browser native databases and there's many articles about how poor they can perform if care is not taken (yoroi maybe an example)

[ross-weir]

This should be benchmarked to see if we can use dexie.js without needing to swap database backends.

An interface that can be implemented for both tauri and dexie.js (indexdb) backed databases is either:

• Complicated to support dexie.js functionality which is hard (maybe impossible) & time consuming to implement for tauri
• Simplified to the point of not being able to utilize performant dexie.js functionality (like database transactions) so we're at risk of indexdb performance issues

If we stick to a swappable backend database interface we can swap out implementations, but its not confirmed a tauri backed database would be more performant, there's still a layer of webview <-> tauri communication which could add up.

Another thought:

If indexdb did become a performance bottleneck we could move to a multiple database model, where we have something like a "main" wallet ex database and a database per wallet (so if there's multiple wallets with many utxos its less of an impact)

https://github.com/dexie/Dexie.js/issues/1033

[ross-weir]

Decision:

Moving to dexie.js. I've performed some really quick/dirty/possibly inaccurate benchmarking and it seems like the performance difference favors dexie it most cases:

• A single find query (in ms):

tauriFind 4.600000023841858 dexieFind 10.600000023841858

We don't have filter implementation for tauri so couldn't test that.

• Doing 4 object creates (in ms):

tauriCreateAccounts 37 dexieCreateAccounts 0.8999999761581421 - without using transactions, etc

• Fetching 5000 accounts for a wallet, getting an idea of a 'fetch utxos for address' type query (in ms):

tauri: 170.29999995231628 dexie: 38.60000002384186

The performance differences start to get even greater as there's more database operations thus more webview <-> tauri communications for the tauri implementation.

Conclusion:

Performance was my main worry about using dexie.js, after some research it seems like it won't be worse (probably even better for a lot of use cases) and we get more benefits:

• A nice API, easy to use
• DB transactions
• Less work to build/maintain
• One implementation
• Portable (all in webview)
• Useful react hooks