> 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 <[email protected]> Sent: Thursday, December 11, 2025 7:31 AM To: Evan Stade <[email protected]> Cc: Mike Taylor <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Abhishek Shanthkumar <[email protected]> Subject: Re: [EXTERNAL] Re: [blink-dev] Web-Facing Change PSA: IndexedDB: SQLite backend (in-memory contexts) You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> 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 | [email protected]<mailto:[email protected]> | Google Chrome<https://www.google.com/chrome> On Wed, Dec 10, 2025 at 11:48 AM 'Evan Stade' via blink-dev <[email protected]<mailto:[email protected]>> wrote: Here's the demo: https://evanstade.github.io/web-storage-demos/idb-txn-scopes (it's also linked in the chromestatus.com<http://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 <[email protected]<mailto:[email protected]>> Sent: Wednesday, December 10, 2025 6:23 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; Abhishek Shanthkumar <[email protected]<mailto:[email protected]>>; Evan Stade <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> 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<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EStorage%3EIndexedDB%22> Web Feature ID indexeddb<https://webstatus.dev/features/indexeddb> Search tags [/features#tags:sqlite]sqlite, [/features#tags:idb]idb, [/features#tags:indexeddb]indexeddb, [/features#tags:leveldb]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<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? 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<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/6938a409.710a0220.1d2509.0190.GAE%40google.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6938a409.710a0220.1d2509.0190.GAE%40google.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]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH0PR00MB10314C5B42189873AB9BA8EDBAA0A%40PH0PR00MB1031.namprd00.prod.outlook.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH0PR00MB10314C5B42189873AB9BA8EDBAA0A%40PH0PR00MB1031.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/PH0PR00MB1031B56D2173D024A5502870BAA1A%40PH0PR00MB1031.namprd00.prod.outlook.com.
