v144 · offline / storage

IndexedDB: SQLite backend (in-memory contexts)

Chromium's IndexedDB implementation is rewritten on top of SQLite, to replace the previous implementation that uses a hybrid of LevelDB and flat files. There is no change to the Web API.

concepts

  1. Incognito IDB

    Step 1 of the IDB SQLite migration: incognito mode flips to SQLite-in-memory. No API change; better reliability under memory pressure.

  2. Round-Trip Cycle

    Time write + read cycles against IDB at 100 / 1k / 10k records. In incognito the new in-memory SQLite backend should hold latency steady.

  3. Transaction Stress

    Fire many concurrent transactions and see p50/p99 latency, throughput, failure rate. The new SQLite backend keeps tail latency tighter under concurrent load.

  4. Schema Inspector

    Enumerate all IDB databases in this origin, expand any of them, and walk every object store: keyPath, autoIncrement, index definitions, and live record counts. Create a demo DB to inspect — the SQLite-backed API surface in one place.

why it shipped

Chromium's IndexedDB implementation suffers from poor reliability and maintainability because it is highly dependent on a database engine (LevelDB) that is not maintained or supported, or as featureful as a full RDBMS. Many sophisticated web apps report high rates of missing or corrupt data, and bugs in the aging backend are hard to find and fix. SQLite is a more suitable replacement for long-term maintainability as it has an active development team and community, and its features like native support for transactions should yield improved reliability.

references