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 <[email protected]> Sent: Saturday, April 25, 2026 12:10 AM To: Evan Stade <[email protected]> Cc: blink-dev <[email protected]>; Abhishek Shanthkumar <[email protected]>; [email protected] <[email protected]> Subject: [EXTERNAL] Re: [blink-dev] Web-Facing Change PSA: IndexedDB: SQLite backend You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> So we killed Web SQL because everyone just used SQLite, and now everyone is just using SQLite for IDB? On Fri, Apr 24, 2026, 3:03 PM 'Evan Stade' via blink-dev <[email protected]<mailto:[email protected]>> wrote: Contact emails [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> 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<https://chromestatus.com/feature/5126896685809664> 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<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EStorage%3EIndexedDB%22> Web Feature ID indexeddb<https://webstatus.dev/features/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<https://evanstade.github.io/web-storage-demos/idb-txn-scopes>. 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<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? 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<https://chromestatus.com/>. -- 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 [email protected]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CHAPR00MB303987F61B2589C048CFF2FFBA2B2%40CHAPR00MB3039.namprd00.prod.outlook.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CHAPR00MB303987F61B2589C048CFF2FFBA2B2%40CHAPR00MB3039.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SA1PR00MB3044C0AB1EED025C39DB474EBA362%40SA1PR00MB3044.namprd00.prod.outlook.com.
