Re: [blink-dev] Web-Facing Change PSA: IndexedDB: SQLite backend (in-memory contexts)

[Mike Taylor]

On 12/9/25 5:34 p.m., Chromestatus wrote:

Contact emails

evan...@microsoft.com, Abhishek.S...@microsoft.com

Specification

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

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 only to in-memory contexts such as Incognito mode in Chromium and Google Chrome. This limits the impact of any new bugs, as well as puts off the need to worry about migration of existing data persisted to disk.

Blink component

Blink>Storage>IndexedDB

Web Feature ID

indexeddb

Search tags

sqlite, idb, indexeddb, leveldb

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 later step where persisted databases are stored with SQLite, and existing data is migrated to SQLite, will have higher associated risks and will have its own PSA. 

Is there a link to a demo? I wonder if this creates a new Incognito mode oracle.

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Security

All data on disk is still segregated by storage bucket (origin). Both new and old implementation are newly fuzz-tested.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

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

Tracking bug

https://issues.chromium.org/issues/436880911

Estimated milestones

Shipping on desktop	144
DevTrial on desktop	144
Shipping on Android	144

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5126896685809664

This intent message was generated by Chrome Platform Status.

--
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/6938a409.710a0220.1d2509.0190.GAE%40google.com.

[Chromestatus]

Contact emails

evan...@microsoft.com, Abhishek.S...@microsoft.com

Specification

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

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 only to in-memory contexts such as Incognito mode in Chromium and Google Chrome. This limits the impact of any new bugs, as well as puts off the need to worry about migration of existing data persisted to disk.

Blink component

Blink>Storage>IndexedDB

Web Feature ID

indexeddb

Search tags

sqlite, idb, indexeddb, leveldb

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 later step where persisted databases are stored with SQLite, and existing data is migrated to SQLite, will have higher associated risks and will have its own PSA.

[Evan Stade]

Here's the demo: https://evanstade.github.io/web-storage-demos/idb-txn-scopes (it's also linked in the chromestatus.com entry)

Yes, when/if the feature is enabled for just incognito and not on-disk, it would create an incognito detector. However, we want to perform A/B measurements during rollout, so it's not a waterfall rollout, which means it's often not a perfect oracle.

We can close this loophole, but not without drawbacks. We could impose the same behavior on the LevelDB backend in Chromium (for IDB in normal profiles). That would be technically easy to do, and could potentially flush out any breakages in Chromium-only sites before the full SQLite rollout. The problem is that it might have a negative perf impact for LevelDB. (We think that overall SQLite will be as fast or better than LevelDB, but this one detail can potentially reduce parallelization, so in isolation it is a detriment.) And this would impede our ability to fairly compare SQLite and LevelDB performance.

Is the goal to eliminate incognito detection altogether (which seems a little bit on the restrictive side, since there are existing unpatched incognito signals), or just to deteriorate the quality of them, or just to make sure none of them become permanently baked into the platform? To deteriorate reliability of the incognito detection, we could:

* hold back 50% of the incognito population indefinitely (which probably still gives us a chance to collect enough metrics/bug reports), or

* impose the same transaction behavior on LevelDB some small percent of the time (to minimize perf impact, but make the detector flaky).

The cost in both of these cases is the headache of non-determinism.

---

From: Mike Taylor <mike...@chromium.org>
Sent: Wednesday, December 10, 2025 6:23 AM
To: blin...@chromium.org <blin...@chromium.org>
Cc: blink-api-ow...@chromium.org <blink-api-ow...@chromium.org>; Abhishek Shanthkumar <Abhishek.S...@microsoft.com>; Evan Stade <evan...@microsoft.com>
Subject: [EXTERNAL] Re: [blink-dev] Web-Facing Change PSA: IndexedDB: SQLite backend (in-memory contexts)

 

On 12/9/25 5:34 p.m., Chromestatus wrote:

Contact emails

evan...@microsoft.com, Abhishek.S...@microsoft.com

Specification

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

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 only to in-memory contexts such as Incognito mode in Chromium and Google Chrome. This limits the impact of any new bugs, as well as puts off the need to worry about migration of existing data persisted to disk.

Blink component

Blink>Storage>IndexedDB

Web Feature ID

indexeddb

Search tags

[/features#tags:sqlite]sqlite, [/features#tags:idb]idb, [/features#tags:indexeddb]indexeddb, [/features#tags:leveldb]leveldb

[Reilly Grant]

I assume that the plan is to migrate non-incognito usage to SQLite as well once we have data on the effect of the migration in the wild. There are other Incognito oracles so I don't think temporarily adding a new one is much of a problem. Among other things, doesn't IndexedDB performance already vary between incognito and non-incognito sessions due to the in-memory storage implementation?

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH0PR00MB10314C5B42189873AB9BA8EDBAA0A%40PH0PR00MB1031.namprd00.prod.outlook.com.

[Evan Stade]

> I assume that the plan is to migrate non-incognito usage to SQLite as well once we have data on the effect of the migration in the wild.

Correct, the incognito-only launch is an extra precaution to verify correctness of our implementation in a low-stakes environment. Given that it doesn't depend on disk i/o, it may or may not provide particularly useful data in terms of perf or reliability (although we will collect that information). The extra caution here compared to other features is due to the risk of data loss --- when a feature persists data, bugs aren't as easy to correct and implementation updates can require their own migration.

> Among other things, doesn't IndexedDB performance already vary between incognito and non-incognito sessions due to the in-memory storage implementation?

It does, and this likely applies to more than one web API, although I've never attempted to create an oracle out of this, and it would probably be pretty flaky since it's also highly dependent on device specs or system load. Perhaps you could create two IDB databases, and if the second is created much faster than the first, that's an indication you're on-the-record/on-disk since the backing store DB would already be loaded/warmed up for the second creation (with LevelDB anyway).

---

From: Reilly Grant <rei...@chromium.org>
Sent: Thursday, December 11, 2025 7:31 AM
To: Evan Stade <evan...@microsoft.com>
Cc: Mike Taylor <mike...@chromium.org>; blin...@chromium.org <blin...@chromium.org>; blink-api-ow...@chromium.org <blink-api-ow...@chromium.org>; Abhishek Shanthkumar <Abhishek.S...@microsoft.com>
Subject: Re: [EXTERNAL] Re: [blink-dev] Web-Facing Change PSA: IndexedDB: SQLite backend (in-memory contexts)

 

You don't often get email from rei...@chromium.org. Learn why this is important

[Mike Taylor]

On 12/11/25 12:04 p.m., Evan Stade wrote:

> I assume that the plan is to migrate non-incognito usage to SQLite as well once we have data on the effect of the migration in the wild.

Correct, the incognito-only launch is an extra precaution to verify correctness of our implementation in a low-stakes environment. Given that it doesn't depend on disk i/o, it may or may not provide particularly useful data in terms of perf or reliability (although we will collect that information). The extra caution here compared to other features is due to the risk of data loss --- when a feature persists data, bugs aren't as easy to correct and implementation updates can require their own migration.

Thanks, that's good to know. And I agree that a temporary "is probably incognito" signal is fine, assuming temporary is on the order of a year, not a decade - good luck shipping :).