Understanding SQLite WASM Storage Quotas & The Origin Private File System
The advent of the official SQLite WebAssembly (WASM) build paired with the Origin Private File System (OPFS) marked a paradigm shift in web architecture. Modern browser-based applications are no longer restricted to lightweight key-value stores or JSON caches. Full ACID-compliant relational databases, vector search indices, and client-side intelligence pipelines can now execute at near-native speeds directly inside user devices.
Why OPFS Outperforms IndexedDB
Historical attempts to run SQLite in the browser (such as sql.js or Absurd-SQL) relied on virtual file systems backed by IndexedDB. Every block write required serializing binary buffers into IndexedDB transactions across the main thread boundary, inducing severe memory spikes and 5x to 10x slower write throughput.
OPFS solves this by introducing FileSystemSyncAccessHandle inside Dedicated Web Workers. This API exposes synchronous, atomic block-level reading and writing directly to the operating system's native file system, completely isolated to the origin.
Cross-Browser Storage Quota Policies
1. Google Chrome & Chromium Engines
Chromium's QuotaManager allocates up to 60% of total free drive space to an individual origin. For a user with 100 GB of free SSD storage, your web application can store up to 60 GB without issue. By default, storage is marked "temporary" (LRU evictable under severe disk pressure). Requesting navigator.storage.persist() upgrades the origin to permanent status.
2. Apple WebKit & Safari Policies
Safari enforces strict anti-tracking and consumer storage boundaries. On macOS, Safari prompts the user when an origin reaches 1 GB. On iOS (iPhone/iPad), standard Safari tabs are capped at ~1 GB, and unvisited origins are subject to Intelligent Tracking Prevention (ITP) 7-day data purging. If your app is added to the iOS Home Screen as a standalone PWA, the 7-day eviction rule is bypassed and multi-gigabyte storage becomes accessible.
3. Mozilla Firefox Gecko Engine
Firefox allocates up to 50% of free disk space per origin, but imposes a default group limit of 10 GB. Calling navigator.storage.persist() in Firefox triggers a visible browser permission prompt requesting user authorization.
The VACUUM 2x Disk Headroom Trap
One of the most dangerous edge cases in client-side SQLite engineering occurs during index optimization or file defragmentation. When you execute VACUUM;, SQLite creates a brand new, clean database file, copies every page, and deletes the old file only when the transaction finishes.
If your database is 1.8 GB and your browser origin only has 1.0 GB of remaining quota headroom, executing VACUUM; will crash mid-operation with SQLITE_FULL (code 13). Always implement pre-flight quota checks before calling VACUUM.