Skip to content

SYSTEM Cited by 1 source

IndexedDB

IndexedDB is the W3C-standardised browser API for durable, asynchronous, indexed key-value storage in JavaScript runtime environments — the standards-track answer to the question "how does a web application persist non-trivial amounts of structured data on the client?"

It is the load-bearing storage primitive when an application needs:

  • Persistence across tab close + browser restart — unlike memory-only stores or session-scoped JavaScript state.
  • Indexed object-store lookups — efficient by-key reads of serialised payloads (issue JSON, query result blobs, etc.).
  • Larger practical quota than localStorage — localStorage is bounded at low single-digit MB and forces string-only storage; IndexedDB scales to working-set-sized caches for real applications.

These three properties are the reasons GitHub's Issues performance team chose IndexedDB as the substrate for its client-side stale-while-revalidate cache for the issues#show route: "Durable browser storage that survives tab closes and browser restarts, unlike memory-only stores; indexed object-store model, which gives efficient key-based lookups for issue query payloads; larger practical quota than localStorage, making it appropriate for real working sets." (Source: sources/2026-05-14-github-from-latency-to-instant-modernizing-github-issues-navigation-performance)

Cost: asynchronous reads are not free on the critical path

IndexedDB's API is fully asynchronous — reads return through a Promise / event-driven flow rather than synchronously. For most application use that's the correct shape (it doesn't block the main thread), but on the critical render path for a soft navigation, even a sub-millisecond IndexedDB lookup introduces an async boundary that prevents synchronous hydration from cache.

GitHub's resolution: layer an in-memory cache tier in front of IndexedDB so hot payloads hit memory synchronously and only cold payloads pay the IndexedDB read cost. "IndexedDB gives persistence across tabs and sessions, but it is still asynchronous and therefore not free on the critical path. The in-memory layer sits between the active in-memory store and persistent storage, allowing hot issue payloads to be served synchronously without paying even the IndexedDB read cost." This is the wiki's pair fast small cache with slow large storage pattern at the browser altitude.

Typical usage shapes

  • Application-managed cache — write-through cache on every successful network fetch; read-first on subsequent navigations; revalidate in the background.
  • Offline-capable workspace — store in-progress user content (drafts, edits) for replay when connectivity resumes.
  • Search index / lookup table — persisted indexed data the client can query without a round trip.
  • Cache substrate for service workers — a service worker reads / writes IndexedDB to serve responses when offline.

In the wiki

  • systems/github-issues-show — canonical wiki instance: IndexedDB as the persistent leg of a stale-while-revalidate cache for the issues#show route, with an in-memory tier in front for synchronous hits. ~33 % cache-hit ratio post-launch → ~96 % after preheating broadly added.
  • patterns/stale-while-revalidate-from-indexeddb — the pattern shape: write-through to IndexedDB, read-first on navigation, background revalidate, reconcile on diff.

Seen in

Last updated · 542 distilled / 1,571 read