IndexedDB: SQLite backend

concepts

1. Bulk Write Stress Test

   A workload that runs the same IndexedDB operations a thousand times in a row — large object inserts, transactional reads, concurrent index lookups — and reports throughput. Useful for spotting regressions or wins between Chrome versions.

2. Transaction Durability

   The actual point of the SQLite migration: reliability. Runs three correctness checks — atomic abort, transaction isolation, strict durability — and reports pass/fail. The hybrid LevelDB backend had bug reports for each class.

3. Migration Readiness Checker

   Run six live IndexedDB tests — open/close, commit/abort, cursor iteration, index correctness, durability modes, quota estimate — and get a readiness score for the SQLite backend switch. Includes a 1000-write stress test.

4. Concurrent Reads Test

   Open N read-only transactions simultaneously and verify that all return correct data — a key claim of the SQLite migration. Configure the number of concurrent transactions, records per store, and reads per transaction. Animated bar graph shows each transaction's progress and pass/fail state.

5. Error Recovery

   Five targeted tests that exercise the error-recovery behavior the SQLite migration was designed to fix: explicit abort, partial-write abort, committed-write survival, constraint-error teardown, and read isolation. Each test checks that the database is in a clean, consistent state after an error.

6. Quota & Persistence Explorer

   Read navigator.storage.estimate() before and after writing to IndexedDB — watching quota, total usage, and IDB-specific usage via usageDetails.indexedDB. Request persistent storage and see whether the browser grants it. A durability timing test runs 'default', 'strict', and 'relaxed' transaction modes against a 200-record batch and compares write times side by side.

   Live API Storage Persistence

why it shipped

The hybrid LevelDB / flat-file backend was responsible for a long tail of corruption bugs and edge-case crashes. SQLite is battle-tested, deeply observable, and the engine already in use across Chromium for many storage subsystems. Moving IndexedDB onto it consolidates the storage stack and unlocks better tooling. The rollout is staged — step 1 was incognito-only, step 2 (this) applies to new persistent stores, step 3 will migrate existing stores. The web API and semantics don't change.

references

• ChromeStatus entry — step 2
• Step 1 (incognito)
• IndexedDB spec