IndexedDB: SQLite backend

concepts

1. Write Integrity Test

   Rapidly write hundreds of records to IndexedDB in multiple concurrent transactions, then read them all back and verify every record survived. See the integrity metrics the SQLite backend is designed to protect.

2. Offline Data Vault

   A practical notes app backed entirely by IndexedDB. Create, read, update, and delete entries — all stored locally, all surviving page reloads. A direct exercise of the same storage layer Chrome just hardened.

3. Concurrent Writers

   Launch up to 8 parallel readwrite transactions each writing 50–200 records simultaneously, then verify every record was persisted. The SQLite backend's write-ahead logging ensures no records are lost — a durability property the old LevelDB+blob hybrid didn't guarantee under heavy concurrency.

4. Transaction Race Demo

   Configure the number of parallel transactions (2–12) and records per transaction, then launch them simultaneously and watch per-transaction status cards update as each one commits. A final integrity check counts every record in the store and confirms zero were lost — showing SQLite WAL's serialisation of concurrent writers in action.

   Live API Concurrency Integrity check

5. Durability Comparison

   Benchmark { durability: 'strict' } vs { durability: 'relaxed' } transactions side by side. Each mode runs the same batch of writes and the commit time is measured. A results table shows per-run timings; a verdict explains what the gap means on your device and when each mode is appropriate with Chrome 150's SQLite backend.

   Benchmark Durability

6. Schema Migration

   Walk through three database versions — add a store, add an index, migrate data — using onupgradeneeded. Each step runs atomically: if the upgrade aborts, the database rolls back to its prior version. Chrome 150's SQLite backend makes this rollback guarantee ironclad, preventing the partial-migration corruption the LevelDB hybrid was prone to. Includes a per-step integrity check.

why it shipped

Chrome's original IndexedDB backend was a combination of LevelDB (for key-value storage) and separate flat files (for large blobs). This hybrid was functional but had well-known edge cases: data corruption after unclean shutdowns, inconsistent behavior when multiple tabs wrote simultaneously, and tricky migration paths for large datasets. The SQLite rewrite unifies all IndexedDB data under a single, battle-tested transactional database engine — one that handles concurrent writers, power-loss scenarios, and partial-write failures natively through WAL (write-ahead logging) and atomic transactions.

Developers do not need to change any code. The SQLite backend passes the full web-platform-tests suite for IndexedDB and ships transparently.

what changes for developers

• No API change — indexedDB.open(), object stores, indexes, cursors, transactions: all identical.
• Improved durability — writes committed in a transaction are less likely to be lost after an unclean shutdown.
• Improved concurrency — multiple tabs writing to the same database see fewer unexpected failures.
• Same origin isolation — each origin's IndexedDB data stays in its own SQLite file; cross-origin access is still impossible.
• Quota behaviour unchanged — the Storage API still governs how much space IndexedDB may use.

references

• ChromeStatus entry
• Chrome for Developers — IndexedDB storage improvements
• MDN — IndexedDB API
• W3C IndexedDB specification