Hey PowerSyncer here :)

Firstly, it's awesome that you are using @sqlite.org/sqlite-wasm for your client-side SQLite database. We really like wa-sqlite ourselves.

We're currently implementing this proposal https://github.com/orgs/powersync-ja/discussions/376, which will speedup the sync throughput a lot - this was a natural next step for us as we have users with massive datasets (syncing a million plus rows).

Sidebar: What has your experience with OPFS+SQLite been like on sqlite-wasm? We have seen our fair share of issues on Safari/web kit.

Hey, nice, looks like I’ll have to rerun the benchmarks soon!

sqlite-wasm with opfs-sahpool has mostly behaved. No OPFS in private mode, storage may be evicted, handles can’t be passed to workers, and webviews may close them when backgrounded.

We open SQLite inside one dedicated worker and proxy other tabs through it, so that avoids some of the mess. Tauri uses native SQLite.

If you are going down that path, might also be useful to read through this PowerSync blog post.

- https://powersync.com/blog/sqlite-optimizations-for-ultra-hi...

Generally I think we have enough chatbots and LLM wrappers in the world. But being able to incorporate a product with just a <script> tag is definitely refreshing.

Author here. The TL;DR is that architecting apps with a synced in-app database eliminates a whole category of work like managing network requests, handling loading states, implementing retry logic, and orchestrating state management because all you have to do is query the local database.

Real-time sync engines are the technology enabling this. I’m working on PowerSync[1] but there’s also cool work being done by Zero[2] and Electric-SQL[3]. Other interesting projects include like InstantDB[4] and Convex[5].

[1] https://powersync.com/

[2] https://zero.rocicorp.dev/

[3] https://electric-sql.com/

[4] https://www.instantdb.com/

[5] https://convex.dev/