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 :).
> 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
<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 <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
<https://wpt.fyi/results/IndexedDB>
*Tracking bug*
https://issues.chromium.org/issues/436880911
<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
<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/a91fbf67-c008-4a11-a34f-149959fcd809%40chromium.org.
