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] | Google Chrome <https://www.google.com/chrome>
On Wed, Dec 10, 2025 at 11:48 AM 'Evan Stade' via blink-dev < [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 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]> > *Sent:* Wednesday, December 10, 2025 6:23 AM > *To:* [email protected] <[email protected]> > *Cc:* [email protected] < > [email protected]>; Abhishek Shanthkumar < > [email protected]>; Evan Stade <[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], [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]. > 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]. > 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/CAEmk%3DMbZWRdT-xZ0q0cLZRAnHterdCWzJVyrOMQ%3DRbGRsXHDZg%40mail.gmail.com.
