I'm planning an offline-first application that needs a relational database with joins, primary keys, foreign keys, and constraints. SQLite seems like a better fit than a key-value store such as IndexedDB, so I'm evaluating SQLite compiled to WebAssembly with OPFS persistence.
The main concerns are browser support, especially in private browsing modes, storage quotas and eviction, the need for COOP and COEP headers when using SharedArrayBuffer, and the restrictions those headers can place on external scripts and stylesheets. Concurrency is another issue: native SQLite handles multiple connections well, while browser-based SQLite often requires a dedicated worker and careful coordination.
Is this setup reliable enough for a production SPA if the application intentionally uses one database worker and perhaps limits users to a single tab? Are there major risks beyond private-mode incompatibilities, storage limits, and browser-specific behavior? I'm also considering IndexedDB as a fallback.
3 Answers
It is getting close, but the browser is still a less predictable environment than a native application. OPFS works in most current browsers, though private browsing—particularly in some Safari and Firefox configurations—can produce vague failures. You also need to plan for quota limits, storage eviction, upgrades, and the possibility that persistence is unavailable.
A dedicated database worker with a single application connection is a reasonable production design today. The main limitation is concurrency: multiple tabs and independent workers are still awkward. A shared worker would be a natural solution, but the APIs needed for SQLite's synchronous file access are not consistently available there yet.
There is a practical workaround for avoiding COOP and COEP: use the SQLite WebAssembly pooled database backend. The tradeoff is that the database becomes locked to one context, so multiple tabs cannot safely open it. For a deliberately single-tab application, that may be perfectly acceptable, and exclusive access can improve performance.
For a serious deployment, treat unsupported storage as a capability to detect rather than assuming it exists. Show a useful fallback or warning, test browser upgrades carefully, and make synchronization or export possible in case the local database is cleared.
IndexedDB is still the safer browser-native choice if broad compatibility and multi-context access matter more than SQL features. But if your data model genuinely benefits from joins, relational constraints, and transactions, SQLite WASM can be a sensible choice when you control the architecture.
There are also experimental approaches that support concurrent reads, although some are limited to particular browsers. I would consider those optional optimizations rather than foundations for a cross-browser product.
That matches the design I'm considering. If I use one dedicated worker, a single tab, and the pooled in-memory-style database option to avoid COOP and COEP, would the remaining concerns mostly be private browsing, quotas, and eviction?