Web-Facing Change PSA: IndexedDB: SQLite backend

[Evan Stade]

Contact emails

evan...@microsoft.com, abhishek.s...@microsoft.com, fer...@google.com

Specification

https://www.w3.org/TR/IndexedDB

Design docs

https://docs.google.com/document/d/1S9Rx67BmCZIP7tpasKaQ2FlV4TL1Z15DitR2kRZs9nw/edit?usp=sharing
https://docs.google.com/document/d/1-N4NqdYjqaWEbfVPYnCg2Ho1u4YK48pUoQ_tSy9SUg8/edit?usp=sharing

Summary

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.

This is expected to improve reliability and, to a lesser extent, performance.

For now this is applied to *new data stores*. This is step 2 of a multi-phase rollout. See the previous Chromestatus entry which tracks step 1, the rollout for in-memory i.e. incognito contexts. Step 3 will consist of migrating existing data from LevelDB stores to SQLite stores.

In this step, the first time a user visits a site, or after clearing site data, new IDB data will be stored in a backend that makes use of SQLite, but existing data stored in LevelDB is unimpacted. See Documentation link below for a list of differences to be aware of.

Blink component

Blink>Storage>IndexedDB

Web Feature ID

indexeddb

Risks

Interoperability and Compatibility

Interop: this work entails a web-visible behavioral change concerning an edge case in IDB transaction scheduling. This change brings Chromium in line with Firefox and Safari. (Both new and old behavior are standards-compliant.) See demo.

Compatibility: This PSA exists primarily to warn of the risk of unintended breakage. The performance characteristics, including reliability, runtime + CPU usage, memory usage, disk access, and storage utilization will all change, to varying extents based on exact details of site usage. This could become problematic in cases where sites are operating at the limits of device abilities (e.g. a kiosk app running on extremely storage-constrained hardware).

Gecko: Shipped/Shipping Firefox uses SQLite for IndexedDB.

WebKit: Shipped/Shipping Safari uses SQLite for IndexedDB.

Web developers: No signals

Other signals:

Activation

There are already many libraries wrapping IndexedDB, and its use is widespread. However, not all sites will be able to immediately take advantage of this feature, because there is not yet a mechanism to migrate data from the implementation that uses LevelDB to that which uses SQLite. Sites that are willing and able to clear user data (such as small local caches of server-stored data) can make use of the feature immediately.

Security

All data on disk is still segregated by storage bucket (origin). Both new and old implementation are newly fuzz-tested. More details: https://docs.google.com/document/d/1IjtPSWrDFw69LbsPsWY5rATO_jAxZF7bm8IndRBBNsU/edit?usp=sharing

Debuggability

existing IndexedDB DevTools support is unimpacted

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/IndexedDB

DevTrial instructions

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB

Tracking bug

https://issues.chromium.org/issues/498644996

Estimated milestones

Shipping on desktop	150
DevTrial on desktop	148
Shipping on Android	150
DevTrial on Android	148
Shipping on WebView	150

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5161589557821440

This intent message was generated by Chrome Platform Status.

[Daniel Herr]

So we killed Web SQL because everyone just used SQLite, and now everyone is just using SQLite for IDB?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CHAPR00MB303987F61B2589C048CFF2FFBA2B2%40CHAPR00MB3039.namprd00.prod.outlook.com.

[Evan Stade]

My understanding is that the biggest issue with WebSQL was that SQLite (and other engines) are not hardened to run attacker-controlled SQL (i.e. that which originates from an untrusted website), and the pace of development on SQLite meant that there was a constant stream of new memory bugs. These days WASM gives sites an alternative path to using SQLite and there are good reasons to use SQLite that way instead of IDB, depending on your use case.

IDB backed by SQLite does not have the same attack surface because Chromium controls the SQL that is run.

---

From: Daniel Herr <danielher...@gmail.com>
Sent: Saturday, April 25, 2026 12:10 AM
To: Evan Stade <evan...@microsoft.com>
Cc: blink-dev <blin...@chromium.org>; Abhishek Shanthkumar <Abhishek.S...@microsoft.com>; fer...@google.com <fer...@google.com>
Subject: [EXTERNAL] Re: [blink-dev] Web-Facing Change PSA: IndexedDB: SQLite backend

 

You don't often get email from danielher...@gmail.com. Learn why this is important