SQLite WASM Storage Quota Estimator
Accurately calculate Origin Private File System (OPFS) limits, browser origin quotas, WAL file overhead, and VACUUM disk safety buffers across Chrome, Safari, Firefox, and mobile WebKit.
Live Browser Hardware Diagnostic Detecting...
Live inspection of navigator.storage.estimate(), OPFS availability, and persistence mode.
Cross-Browser Storage Capacity Simulator
Predict exact storage exhaustion limits, WAL log expansion, and defragmentation headroom for target user devices.
Chromium grants up to 60% of total available disk volume per origin, with seamless OPFS sync handle access in Web Workers.
Target database fits comfortably within client origin quota. Chromium will allow seamless reads and writes via OPFS without user prompts.
SQLite WASM OPFS Defensive Code Patterns
Tested snippets to handle storage permission gates, pre-flight checks, and VACUUM safety.
// 1. Safe Storage Persistence Request Pattern
async function ensurePersistentStorage() {
if (!navigator.storage || !navigator.storage.persist) {
console.warn("StorageManager API not supported in this environment");
return false;
}
// First check if already persistent
const isPersisted = await navigator.storage.persisted();
if (isPersisted) {
console.log("Storage is already persistent and immune to LRU eviction");
return true;
}
// Request persistence from browser
const granted = await navigator.storage.persist();
if (granted) {
console.log("Storage persistence successfully GRANTED by user/browser");
} else {
console.warn("Storage persistence DENIED: origin remains best-effort (LRU evictable)");
}
return granted;
}
Chromium Quota Manager
Chromium (Chrome, Edge, Opera) allocates up to 60% of total free drive storage to a single origin. Origin storage is partitioned into "temporary" (LRU evictable under low disk) and "persistent". Once granted persistence, the origin is never evicted automatically.
WebKit & Safari 7-Day Cap
Safari prompts when an origin reaches 1GB. On iOS, regular Safari tabs are capped at ~1GB and subject to Intelligent Tracking Prevention (ITP) 7-day deletion without user visits. Converting your app into an installed PWA unlocks multi-GB storage stability.
The VACUUM 2x Trap
VACUUM writes an entirely new clone of the database to eliminate free page fragmentation. If your database is 1.5GB and your origin has only 1.2GB of free quota remaining, running VACUUM fails abruptly with SQLITE_FULL. Always maintain 120% free headroom.
Frequently Asked Questions
Deep architectural insights on SQLite WASM, OPFS, and browser storage longevity.
What is the storage quota limit for SQLite WASM in modern browsers? ↓
Storage limits depend on your client's browser engine and available free drive space:
- Google Chrome & Chromium: Up to 60% of available total disk space per origin. On a 512GB laptop with 200GB free, your web app can store up to 120GB!
- Apple Safari Desktop: Prompts the user when exceeding 1GB, granting access up to roughly 60% of disk space upon confirmation.
- Mobile Safari (iOS): Standard web tabs face a strict 1GB limit and may be purged after 7 days without interaction. Installing the app as an iOS Home Screen PWA significantly relaxes quota constraints.
- Mozilla Firefox: Up to 50% of free disk space per origin, subject to an overall 10GB default group cap.
Why does SQLite VACUUM require 2x the database size in OPFS? ↓
VACUUM command defragments the database file by creating a brand-new, clean copy on disk and copying all pages sequentially. During this operation, both the original database file and the new temporary file exist simultaneously in the Origin Private File System directory. If your origin lacks sufficient quota for both files, SQLite will throw an unrecoverable SQLITE_FULL error.
Why is OPFS so much faster than IndexedDB for SQLite WASM? ↓
FileSystemSyncAccessHandle. When running in a Dedicated Web Worker, SQLite WASM writes raw binary pages directly to the underlying OS disk blocks synchronously, bypassing DOM thread hops and JSON/Blob serialization. In contrast, older IndexedDB VFS approaches (like Absurd-SQL or Emscripten IDBFS) serialize binary blocks through IndexedDB transactions, resulting in heavy memory pressure and high I/O latency.
How do I safeguard client databases from automatic browser eviction? ↓
navigator.storage.persist() (preferably triggered after a user interaction or login), you request "persistent" status. Once persistent storage is granted, browsers will never clear your SQLite files without direct manual intervention by the user via browser settings.
What happens when SQLite WASM hits the browser quota ceiling? ↓
QuotaExceededError DOMException, which the SQLite VFS translates into SQLITE_FULL (code 13). Ongoing write transactions will fail and roll back. To prevent ungraceful crashes, web apps should implement pre-flight storage estimates using navigator.storage.estimate() before batch operations.