a standardized, easy-to-use client-side sql-database is sorely needed to advance the state of frontend-development beyond its current dependency on backend-servers for state-management.
my current experience with sql.js (wasm-sqlite3) indicate its suitable for such role. at our company, we have a frontend-product that no longer relies on sql-server, with all its state-management migrated to sql.js (and persisted as indexeddb blobs). the product runs sql.js fine on chrome, firefox, and edge (albeit slowly) with the following anecdata performance numbers:
time to ingest 500,000 row csv (~100 MB) into sql.js web-worker (and persist in indexeddb):
- chrome: 15 seconds
- firefox: 20 seconds
- edge: 90 seconds
time to run [product-specific] sql-queries on 500,000 row table in sql.js web-worker:
- chrome: 35 seconds
- firefox: 35 seconds
- edge: 65 seconds
- debate on whether including currently released sql.js v1.0.0 (or minor update to it) as a builtin browser/webworker-api is a good-idea
i’m not knowledgeable about security. but the initial api will not address persistence, to keep the scope manageable – users are expected to manage persistence themselves via indexeddb/kv-storage/localforage.
possible future addon proposals (but out-of-scope of initial proposal):
- allow indexeddb to persist 1gb sqlite3-blobs (chrome currently hard-limits indexeddb to 120 MB blobs).
- add easy-to-use, web-worker builtin-api to ingest 1gb csv
- future release of sql.js should have ability to attach multiple database/csv 
- future release of sql.js should properly catch web-worker exceptions and pass them to main thread 
 sql.js issue 88 - A way to attach multiple databases?
 sql.js issue 288 - fix error-handling in worker