IndexedDB vs localStorage: What Your Browser Can Store

Use localStorage when your data fits in five megabytes and is read once on page load. Use IndexedDB when you need to query, paginate, store blobs, or exceed a few kilobytes per user. The two are different categories of storage, not different points on a spectrum — the choice is structural, about API shape, threading model, and capacity, not about taste.

The WHATWG Storage Standard now formally pins localStorage to a quota of "5 × 2²⁰ (i.e., 5 mebibytes)" per origin ¹, and the HTML Living Standard defines its API as fully synchronous: every setItem call blocks the main thread until the bytes hit disk ². IndexedDB, in contrast, is a W3C Working Draft 3.0 (13 August 2025) ³ for an asynchronous, transactional, indexed object store that ships in 96.13% of browsers ⁴ and can — on Firefox — hold up to 10 GiB of best-effort data per site, or 50% of disk space (capped at 8 TiB) once persistent storage is granted ⁵. The gap between the two APIs is not a matter of degree. It is a different category of storage.

What localStorage is

localStorage is a synchronous, string-only, key-value store with a 5 MiB-per-origin quota defined by the WHATWG Storage Standard ¹. The HTML Living Standard exposes it as a Storage object on window; both keys and values are typed DOMString ². No transactions, no indexes, no blobs, no async variant. Six methods total. It was designed in 2009 as a slightly-larger cookie that does not round-trip with every HTTP request ⁶.

The interface is six methods: setItem, getItem, removeItem, clear, length, and key(n) ². Values are coerced to strings on write and returned as strings on read; storing an object requires JSON.stringify and JSON.parse on every round trip. Writes that exceed the quota throw a QuotaExceededError ². Reads are O(1) but block the event loop — RxDB's measurements put a small localStorage read at 0.0052 ms and a write at 0.017 ms on Chrome 128 ⁷, faster than IndexedDB per call but synchronous, which is the whole problem at scale. A storage event fires on other documents from the same origin when a value changes ².

The standardization history clarifies what the API was for. The first Web Storage draft, then called "DOM Storage," was carved out of the larger HTML5 effort as a deliberately small alternative to cookies — designed to hold "megabytes of user data" for performance reasons but not much more ⁶. It is a cookie that survives reload and skips the request headers. It was never meant to be a database.

What IndexedDB is

IndexedDB is an asynchronous, transactional object store with secondary indexes, cursors, and structured-clone value support, specified by W3C as a Working Draft 3.0 dated 13 August 2025 ³. The draft calls an object store "the primary storage mechanism for storing data in a database" ³, and MDN labels IndexedDB "a low-level API for client-side storage of significant amounts of structured data, including files/blobs" ⁸. Multiple object stores can be opened inside a single transaction, and the database itself is versioned for schema migration ⁹.

Every operation returns an IDBRequest whose onsuccess or onerror handler fires when the underlying transaction commits or rolls back ¹⁰. Three transaction modes — readonly, readwrite, and (for schema migrations) versionchange — guarantee ACID semantics across multiple object stores ^{9 11}. Values are stored via the structured clone algorithm, which means Dates, Maps, Sets, ArrayBuffers, Blobs, and Files round-trip natively — no JSON.stringify ^{3 8}. Secondary indexes are defined at upgrade time and queried through IDBKeyRange cursors. IndexedDB 1.0 became a W3C Recommendation on 8 January 2015; 2.0 on 30 January 2018 added getAll(); 3.0 has been a Working Draft since 11 March 2021 and remains one as of April 2026 ¹².

Browser support is broad. Caniuse reports 96.13% global support as of April 2026, with full coverage in Chrome 23+, Firefox 10+, Safari 10+, and Edge 79+ ⁴. The historical gotchas — Safari's flaky early implementations, Firefox's transaction-inactive race with promises ¹³ — are largely closed; modern wrappers handle the remaining edges.

Side-by-side comparison

The table below is the load-bearing summary. Treat the cells as facts to verify, not conclusions to memorize. Every row cites a primary source — the WHATWG Storage Standard, the W3C IndexedDB draft, MDN, RxDB's Chrome 128 benchmarks, caniuse, the WebKit blog. Skim the table, then read the row you do not believe.

Above ~500 KB payloads, IndexedDB cuts page-response time by 40%+ — localStorage's blocking writes monopolize the main thread, and the larger the payload the wider the gap ¹⁵. Per-call timings flatter localStorage. Throughput at the tab level does not.

Performance

Performance comparisons are easy to misread. localStorage looks faster per operation; IndexedDB looks faster at scale. RxDB's measurements on Chrome 128 — simple JSON documents — put localStorage writes at 0.017 ms and IndexedDB writes at 0.17 ms ⁷. That is a 10× per-call gap. It inverts the moment you write enough to block the renderer, because every localStorage call is synchronous and the main thread waits for disk. Batched IndexedDB writes pay one transaction cost across many records and stay off the critical path.

Thomas Steiner, a Chromium engineer, published in August 2024 that Chrome now applies Snappy compression to IndexedDB values stored as external files and moves smaller compressed payloads back into the LevelDB store. The result, per his benchmark: "1 MB structured data payloads are delivered from disk to page in about a quarter the time," with synthetic operations "two to three times faster than before" ²⁰. None of those gains apply to localStorage, because there is nothing in the localStorage spec to compress against ².

The actual lesson from RxDB's deeper analysis is that IndexedDB's bottleneck is transaction handling, not data throughput. One thousand documents inside a single transaction take about 80 ms; the same thousand spread across one transaction each take roughly two seconds ¹⁶. Batch the writes and the gap narrows. Open one transaction per insert and it widens by 25×. localStorage has no such knob — every setItem is its own little transaction, and the main thread waits.

When to use localStorage

Use localStorage for state that is small, string-typed, read once on page load, and rare to write. Theme preference. The last-visited route. A flag for "user dismissed the onboarding banner." Cookies round-trip with every request; localStorage skips that overhead ². For data that fits in a few kilobytes, the synchronous API is a feature — there is no awaitable promise to thread through your renderer, and reads complete inside the same microtask as the code that asked for them.

The 5 MiB quota is generous for these uses and absurd for almost anything else. A single screenshot, encoded as base64 into a localStorage string, can blow the entire origin budget in one write. The MDN entry for localStorage warns that the protocol partitions storage — http://example.com and https://example.com are separate — and that private-browsing data is cleared when the last private tab closes ²¹. Plan around both.

When to use IndexedDB

Use IndexedDB when your data is records, not flags — and when you will query by anything other than a primary key. Notes apps, email clients, image editors, offline queues, and PWAs caching API responses all fit. The W3C IndexedDB 3.0 draft (13 August 2025) was built for these shapes: indexed lookups, range cursors, multi-store ACID transactions ³.

Pete LePage, on web.dev, recommends IndexedDB as the default for application data: "For the network resources necessary to load your app, use the Cache Storage API. For file-based content, use the Origin Private File System (OPFS). For other data, use IndexedDB (with a promises wrapper)." ¹⁴ That last clause matters. The raw IndexedDB API is event-driven and callback-heavy; almost nobody writes against it directly in 2026. Wrappers (the next section) absorb the ceremony.

Code: the same task in both APIs

The clearest argument for IndexedDB is the diff between storing notes in localStorage and storing them in IndexedDB with an index on updatedAt. localStorage looks shorter only until you query the result — then the missing index forces a full scan and every value is re-parsed from a string. Below: the same task written three ways.

localStorage — store and read a note:

// localStorage: strings only. Everything goes through JSON.
const note = { id: "n_1", title: "Hello", body: "First note", updatedAt: Date.now() };

localStorage.setItem(`note:${note.id}`, JSON.stringify(note));     // blocks main thread

const raw = localStorage.getItem(`note:${note.id}`);                // blocks main thread
const parsed = raw ? JSON.parse(raw) : null;

// Want all notes updated this week? You read every key:
const recent = Object.keys(localStorage)
  .filter((k) => k.startsWith("note:"))
  .map((k) => JSON.parse(localStorage.getItem(k)))
  .filter((n) => n.updatedAt > Date.now() - 7 * 24 * 3600 * 1000);

There is no index on updatedAt. The filter scans every key — and every value is re-parsed from a string on every read.

IndexedDB (raw) — same task with an index on updatedAt:

// Open or upgrade
const open = indexedDB.open("mnmnote", 1);

open.onupgradeneeded = (event) => {
  const db = event.target.result;
  const store = db.createObjectStore("notes", { keyPath: "id" });
  store.createIndex("byUpdatedAt", "updatedAt", { unique: false });   // queryable index
};

open.onsuccess = (event) => {
  const db = event.target.result;
  const tx = db.transaction("notes", "readwrite");                   // explicit transaction
  const store = tx.objectStore("notes");

  store.put({ id: "n_1", title: "Hello", body: "First note", updatedAt: Date.now() });

  tx.oncomplete = () => {
    const ro = db.transaction("notes", "readonly").objectStore("notes");
    const range = IDBKeyRange.lowerBound(Date.now() - 7 * 24 * 3600 * 1000);

    ro.index("byUpdatedAt").openCursor(range).onsuccess = (e) => {
      const cursor = e.target.result;
      if (!cursor) return;
      console.log(cursor.value);                                     // one note per cursor step
      cursor.continue();
    };
  };
};

Every method name is from the W3C draft: createObjectStore, createIndex, transaction, objectStore, put, IDBKeyRange.lowerBound, openCursor, continue ^{3 10 9 11}. The verbosity is real. So is the index.

IndexedDB through Dexie — the same task, half the code:

import Dexie from "dexie";

const db = new Dexie("mnmnote");
db.version(1).stores({ notes: "id, updatedAt" });                    // string DSL = key + indexes

await db.notes.put({ id: "n_1", title: "Hello", body: "First note", updatedAt: Date.now() });

const recent = await db.notes
  .where("updatedAt")
  .above(Date.now() - 7 * 24 * 3600 * 1000)
  .toArray();

Dexie is "a Minimalistic Wrapper for IndexedDB" ¹⁸, maintained since 2014 by David Fahlander, currently at v4.4.2 (released 31 March 2026) ²², 14.3k stars on GitHub, "widely used by 100,000 of web sites" per the Dexie homepage ²³. Jake Archibald's idb library — 1.19 kB brotli, 7.3k stars — keeps the IDB API surface intact but returns promises ¹⁹. Mozilla's localForage (25.8k stars) provides a localStorage-shaped API over IndexedDB for code already written against the synchronous interface ²⁴. Three different libraries, three different opinions about what an IndexedDB wrapper should be. For a full worked tour of Dexie in a notes app — schema, hooks, sync — see our companion post on building offline-first with Dexie.js.

Migration paths

Moving a small app from localStorage to IndexedDB is mechanical: open a versioned database, read every localStorage key once, write the parsed objects into an object store, then localStorage.clear() after a successful commit. Doing it the other direction is rare and usually a mistake — IndexedDB databases routinely exceed the 5 MiB localStorage quota by orders of magnitude.

The tricky part of moving from localStorage is the synchronous-to-asynchronous transition. Code that called JSON.parse(localStorage.getItem("settings")) during render now has to await a promise — which means components either suspend or render with a fallback. React 19's use() hook, which unwraps promises inside Suspense boundaries, helps here ²⁵. So does loading the data once at app boot and caching it in a Zustand or signal store. Code that wrote to localStorage on every keystroke needs throttling; IndexedDB's per-call latency rewards batched writes inside a single transaction ¹⁶.

The reverse direction — IndexedDB to localStorage — only makes sense if the data has shrunk to a handful of keys (think: a settings app dropping a feature). Otherwise the 5 MiB ceiling will catch you. The Storage Standard formally pins that figure for localStorage, and the spec does not contemplate raising it ¹.

Who should not use IndexedDB

IndexedDB is the wrong tool for four classes of data: tiny configuration flags read once at boot; data that needs to survive seven days of Safari with no user interaction; blobs measured in tens of gigabytes that you'll write byte-by-byte; and small relational datasets you want to inspect live in DevTools without a custom panel. For each of these, IndexedDB is more machinery than the problem deserves.

For the configuration case, a setItem("theme", "dark") call is fewer lines and one synchronous read ². For the Safari case, the browser deletes all "script-writable storage" — IndexedDB, localStorage, service workers, Cache API — after seven days of no engagement with the origin, per John Wilander's 24 March 2020 WebKit post ²⁶. For the multi-gigabyte byte-by-byte case, OPFS, with its createSyncAccessHandle in a worker, was built for that workload ^{27 28}. For the DevTools-inspection case, Chrome's own docs flag that the IndexedDB DevTools view does not auto-refresh — you have to right-click and reload the database to see new writes — which makes localStorage's instant table view a better fit when you are debugging a five-key settings store ²⁹.

The seven-day Safari rule is the most surprising. PWAs installed to the home screen are exempt (they run on a separate counter tied to app usage) ²⁶, but ordinary websites accessed in Safari tabs get a clock. Apps that need durable browser-only storage on Safari either prompt for persistent storage via navigator.storage.persist() ³⁰ — granted automatically on Chrome based on engagement signals, but only on Firefox after a user prompt ³⁰ — or accept that a quiet user is an evicted user.

What's coming: OPFS, buckets, and Storage 3.0

The Origin Private File System (OPFS) is the most consequential addition since IndexedDB itself. It exposes a per-origin filesystem with in-place writes through FileSystemSyncAccessHandle in Web Workers — fast enough that the SQLite team built @sqlite.org/sqlite-wasm to run a full SQLite database backed by OPFS files ²⁸. MDN calls OPFS files "highly optimized for performance" and notes its "in-place write access to its content," Baseline since March 2023 ²⁷.

RxDB's measurements suggest OPFS sync-access handles are roughly 4× faster than IndexedDB for the read-heavy workloads where wa-sqlite shines ¹⁶. The trade-off is complexity: OPFS only does synchronous file ops inside a worker, no DevTools view of the files exists, and you have to bring your own query engine. For most note, document, and CRUD apps in 2026, IndexedDB remains the default; OPFS is the upgrade you reach for when query complexity or write throughput demands SQL.

The Storage Standard, edited by Anne van Kesteren and last updated 15 March 2026, also formalizes the storage bucket model — a way for apps to partition their data into independently evictable units, request persistence per bucket, and reason about quota at finer grain than "the whole origin" ¹. Buckets are not yet shipped everywhere, but the spec direction is clear: storage on the web is moving from one big bag of bytes per origin to a small filesystem of named, quota-managed compartments.

Frequently Asked Questions

What is the maximum size of localStorage? The WHATWG Storage Standard pins localStorage to a quota of "5 × 2²⁰ (i.e., 5 mebibytes)" per origin ¹. In practice browsers honor that figure, with sessionStorage limited separately and the combined Web Storage cap usually 10 MiB. Exceeding it throws a QuotaExceededError and the write is rejected.

Is IndexedDB slower than localStorage? Per operation, yes — RxDB's Chrome 128 measurements put localStorage writes at 0.017 ms versus IndexedDB at 0.17 ms ⁷. At scale, no. localStorage's synchronous API blocks the main thread, so payloads above ~500 KB make IndexedDB faster overall ^{15 16}.

Can I store images and blobs in IndexedDB? Yes. IndexedDB uses the structured clone algorithm, which natively serializes Blob, File, ArrayBuffer, ImageData, Date, Map, and Set without any string conversion ^{3 8}. localStorage cannot do this — values are strict DOMString, so blobs would have to be base64-encoded (a ~33% size penalty) and the 5 MiB quota would still apply ^{1 2}.

Does IndexedDB work offline? Yes. IndexedDB is a client-side database with no network dependency — once the page loads, reads and writes work entirely against the browser's local store ⁸. It is the storage backbone of most PWAs, including offline-first note apps and editors, paired with the Cache Storage API for static assets ¹⁴.

Will Safari delete my IndexedDB data? Possibly. Per John Wilander's March 2020 WebKit post, Safari evicts all "script-writable storage" — IndexedDB, localStorage, service worker caches — after seven days of Safari use without user interaction on the site ²⁶. PWAs installed to the home screen are exempt. To opt out, request persistent storage via navigator.storage.persist() ³⁰.

Do I need a library to use IndexedDB? Not strictly, but almost everyone uses one. The raw API is event-driven across roughly fourteen interfaces — IDBDatabase, IDBTransaction, IDBObjectStore, IDBRequest, IDBIndex, IDBKeyRange, and friends ^{10 9 11}. Dexie (14.3k stars) wraps it with a fluent query API ^{22 23}; Jake Archibald's idb (7.3k stars, 1.19 kB brotli) keeps the surface intact but returns promises ¹⁹; localForage (25.8k stars) presents a localStorage-shaped facade ²⁴.

Is localStorage deprecated? No. The HTML Living Standard's Web Storage section was last edited 14 May 2026, and the Storage Standard's localStorage quota is still formally specified ^{1 2}. localStorage remains the right tool for tiny synchronous configuration. What is deprecated is Web SQL Database, whose specification was halted on 18 November 2010 and explicitly redirects implementers to "Web Storage and Indexed Database API" ³¹.

Closing

Storage is destiny in browser apps. It is the first decision that compounds — through every render, every migration, every browser quirk. localStorage is the right answer for a string and a flag; IndexedDB is the right answer for a corpus.

For a note app the choice is never close: it stores notes, not preferences, and a note app whose data ceiling is 5 MiB is a note app that ends at roughly 1,500 average-length markdown files. The structural ceiling and the structural floor of the product are the same shape.

If your app is a flag, write a flag. If your app is a notebook, write a database.

References

Grouped by tier. URLs verified live as of 2026-05-15.

Standards / specifications

Engineering / primary technical sources

IndexedDB interface references (MDN)

• MDN. IDBDatabase (one-sentence definition; createObjectStore, deleteObjectStore, transaction, close). https://developer.mozilla.org/en-US/docs/Web/API/IDBDatabase. Last modified 23 June 2025.
• MDN. IDBIndex. https://developer.mozilla.org/en-US/docs/Web/API/IDBIndex.
• MDN. IDBKeyRange. https://developer.mozilla.org/en-US/docs/Web/API/IDBKeyRange.
• MDN. IDBCursor. https://developer.mozilla.org/en-US/docs/Web/API/IDBCursor.
• MDN. IDBCursorWithValue. https://developer.mozilla.org/en-US/docs/Web/API/IDBCursorWithValue.
• MDN. IDBOpenDBRequest. https://developer.mozilla.org/en-US/docs/Web/API/IDBOpenDBRequest.
• MDN. IDBVersionChangeEvent. https://developer.mozilla.org/en-US/docs/Web/API/IDBVersionChangeEvent.
• MDN. IDBFactory. https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory.
• MDN. IDBFactory.open(). https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/open.
• MDN. IDBObjectStore. Last modified 24 October 2025. Methods: add, put, get, getAll, getKey, delete, clear, count, openCursor, openKeyCursor, createIndex, deleteIndex, index. https://developer.mozilla.org/en-US/docs/Web/API/IDBObjectStore.
• MDN. Using IndexedDB. Last modified 8 February 2026. Canonical worked example with createObjectStore, createIndex, put, get. https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB.
• MDN. Web Storage API (overview). Last modified 22 February 2025. Synchronous behavior explicitly stated. https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API.
• MDN. Window.sessionStorage. Last modified 30 November 2025. https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage.
• MDN. Storage interface. https://developer.mozilla.org/en-US/docs/Web/API/Storage.
• MDN. Storage.setItem. https://developer.mozilla.org/en-US/docs/Web/API/Storage/setItem.
• MDN. Storage.getItem. https://developer.mozilla.org/en-US/docs/Web/API/Storage/getItem.
• MDN. Storage.removeItem. https://developer.mozilla.org/en-US/docs/Web/API/Storage/removeItem.
• MDN. Storage.clear. https://developer.mozilla.org/en-US/docs/Web/API/Storage/clear.
• MDN. Storage.key. https://developer.mozilla.org/en-US/docs/Web/API/Storage/key.
• MDN. Storage.length. https://developer.mozilla.org/en-US/docs/Web/API/Storage/length.
• MDN. StorageEvent. https://developer.mozilla.org/en-US/docs/Web/API/StorageEvent.
• MDN. Window.storage_event. https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event.
• MDN. Structured clone algorithm. https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm.
• MDN. StorageManager. https://developer.mozilla.org/en-US/docs/Web/API/StorageManager.
• MDN. StorageManager.estimate(). https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/estimate.
• MDN. StorageManager.persisted(). https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/persisted.
• MDN. navigator.storage. https://developer.mozilla.org/en-US/docs/Web/API/Navigator/storage.
• MDN. Cache API. https://developer.mozilla.org/en-US/docs/Web/API/Cache.
• MDN. File System Access API. https://developer.mozilla.org/en-US/docs/Web/API/File_System_API.
• MDN. FileSystemSyncAccessHandle. https://developer.mozilla.org/en-US/docs/Web/API/FileSystemSyncAccessHandle.
• MDN. FileSystemDirectoryHandle. https://developer.mozilla.org/en-US/docs/Web/API/FileSystemDirectoryHandle.
• MDN. FileSystemFileHandle. https://developer.mozilla.org/en-US/docs/Web/API/FileSystemFileHandle.
• MDN. Blob. https://developer.mozilla.org/en-US/docs/Web/API/Blob.
• MDN. File. https://developer.mozilla.org/en-US/docs/Web/API/File.
• MDN. QuotaExceededError. https://developer.mozilla.org/en-US/docs/Web/API/QuotaExceededError.

Engineering blogs and benchmarks

• web.dev. Work with IndexedDB. Last updated 15 January 2024. Canonical openDB/createObjectStore/transaction example. https://web.dev/articles/indexeddb.
• web.dev. IndexedDB best practices. Author Philip Walton; last updated 8 June 2017. Recommends error handling, in-memory mirroring, granular records. https://web.dev/articles/indexeddb-best-practices.
• web.dev. Offline data storage. PWA Learn module. Last updated 10 January 2022. Recommends Cache Storage for network resources, IndexedDB for structured data. https://web.dev/learn/pwa/offline-data.
• web.dev. Complexity management (PWA Learn). https://web.dev/learn/pwa/complexity/.
• web.dev. Cache Storage API docs. https://web.dev/learn/pwa/caching/.
• Chrome for Developers. View and change IndexedDB data. Author: Kayce Basques. Last updated 18 March 2019. DevTools-side notes; no auto-refresh of IndexedDB views. https://developer.chrome.com/docs/devtools/storage/indexeddb.
• Chrome for Developers. Origin private file system. https://developer.chrome.com/docs/web-platform/origin-private-file-system.
• Chrome Platform Status. IndexedDB 3.0 features. https://chromestatus.com/features.
• WebKit Blog. Full Third-Party Cookie Blocking and More. Wilander, 24 March 2020. Seven-day cap detail. https://webkit.org/blog/10058/full-third-party-cookie-blocking-and-more/.
• chromium.org. Speed Hall of Fame — IndexedDB performance regression entry, Joshua Bell. https://www.chromium.org/developers/speed-hall-of-fame/.
• W3C public-webapps mailing list. Re: IndexedDB: Thoughts on implementing IndexedDB, Joshua Bell, 30 July 2013. https://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0211.html.
• W3C public-webappsec list. Requesting security review of IndexedDB API, Joshua Bell, 9 February 2017. https://lists.w3.org/Archives/Public/public-webappsec/2017Feb/0004.html.
• W3C public-webapps. IndexedDB, Blobs and partial Blobs - Large Files, Joshua Bell, 4 December 2013. https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0743.html.
• W3C public-webapps. [IndexedDB] Closing connection in a versionchange transaction, Joshua Bell, 30 November 2012. https://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0624.html.

Library sources and ecosystems

• Dexie.js homepage. "IndexedDB made simple. Add cloud sync for auth, storage, with real-time updates." David Fahlander, founder. https://dexie.org/.
• npm. dexie. https://www.npmjs.com/package/dexie.
• npm. idb. https://www.npmjs.com/package/idb.
• npm. localforage. https://www.npmjs.com/package/localforage.
• GitHub. dfahlander/Dexie.js (legacy redirect). https://github.com/dfahlander/Dexie.js.
• GitHub. jakearchibald/idb-keyval. "Super-simple promise-based keyval store implemented with IndexedDB." 295 bytes brotli; 3.2k stars. https://github.com/jakearchibald/idb-keyval.
• GitHub. pubkey/rxdb. "A fast, local-first, reactive database for JavaScript applications." 23.2k stars. https://github.com/pubkey/rxdb.
• GitHub. pouchdb/pouchdb. "Inspired by Apache CouchDB; designed to run well within the browser." 17.6k stars. https://github.com/pouchdb/pouchdb.
• GitHub. google/lovefield. Relational database in pure JavaScript; archived 10 January 2023. 6.8k stars. https://github.com/google/lovefield.
• GitHub. aaronpowell/db.js. "Wrapper for IndexedDB to make it easier to work against, making it look more like a queryable API." 824 stars. https://github.com/aaronpowell/db.js.
• GitHub. ujet/jsstore. IndexedDB-based SQL-like JS database. https://github.com/ujjwalguptaofficial/JsStore.
• GitHub. erikolson186/zangodb. MongoDB-like IndexedDB wrapper. https://github.com/erikolson186/zangodb.
• GitHub. WICG/file-system-access. File System Access API. https://github.com/WICG/file-system-access.
• GitHub. raineorshine/indexeddb-benchmark. "IndexedDB performance benchmark." Notes Safari slowdowns with many stores; Chrome {durability: "relaxed"} write gains. https://github.com/raineorshine/indexeddb-benchmark.
• GitHub. sqlite/sqlite-wasm releases. https://github.com/sqlite/sqlite-wasm/releases.

Mainstream technical press and community

• Wikipedia. Web storage. Standardized by W3C and WHATWG; varying browser quotas. https://en.wikipedia.org/wiki/Web_storage.
• Wikipedia. Indexed Database API. Implementation history; IE 10, Firefox 4, Chrome 11. https://en.wikipedia.org/wiki/Indexed_Database_API.
• Wikipedia. Web SQL Database. Deprecation, IndexedDB as successor. https://en.wikipedia.org/wiki/Web_SQL_Database.
• Wikipedia. Progressive web app. https://en.wikipedia.org/wiki/Progressive_web_application.
• Wikipedia. Service worker. https://en.wikipedia.org/wiki/Service_worker.
• DEV Community. LocalStorage vs IndexedDB: JavaScript Guide (Storage, Limits & Best Practices). TenE, 19 March 2025. Comparison table covering type, capacity, performance, queries, transactions. https://dev.to/tene/localstorage-vs-indexeddb-javascript-guide-storage-limits-best-practices-fl5.
• DEV Community. 9 differences between IndexedDB and LocalStorage. https://dev.to/armstrong2035/9-differences-between-indexeddb-and-localstorage-30ai.
• DEV Community. Testing storage limits of localStorage and sessionStorage in Chrome. https://dev.to/tommykw/testing-storage-limits-of-localstorage-and-sessionstorage-in-chrome-21ab.
• DEV Community. Browser Storage Comparison: sql.js vs IndexedDB vs localStorage, recca0120, March 2026. https://dev.to/recca0120/browser-storage-comparison-sqljs-vs-indexeddb-vs-localstorage-158o.
• Browsee. Browser Storage: A Comparative Analysis of IndexDB, Local Storage, and Session Storage. https://browsee.io/blog/unleashing-the-power-a-comparative-analysis-of-indexdb-local-storage-and-session-storage/.
• Hacker News. Why IndexedDB is slow and what to use instead (rxdb article discussion). https://news.ycombinator.com/item?id=29314766.
• LogRocket Blog. localStorage vs. IndexedDB vs. cookies for web app storage. https://blog.logrocket.com/localstorage-vs-indexeddb-vs-cookies/.
• Smashing Magazine. Local-First Web Development. Historical overview of browser data architectures.
• Hashnode. AMA — I am Surma, Web Advocate and Engineer at Google. Surma on storage and main-thread cost. https://hashnode.com/post/i-am-surma-web-advocate-and-engineer-at-google-ask-me-anything-cjslgcaha00fy7bs2mgap4rjd.
• javascript.info. IndexedDB. Long-form IDB tutorial. https://javascript.info/indexeddb.
• DeepWiki / Excalidraw. Binary Files and Image Management. Documents Excalidraw's IndexedDB image store via LocalData.fileStorage. https://deepwiki.com/excalidraw/excalidraw/6.3-frame-rendering-and-management.
• GitHub. excalidraw/excalidraw#1280 — Explore migrating to IndexedDB for data storage. https://github.com/excalidraw/excalidraw/issues/1280.

Academic / canonical

• Kleppmann, M., Wiggins, A., van Hardenberg, P., & McGranaghan, M. (2019). Local-first software: You own your data, in spite of the cloud. Ink & Switch / Onward! 2019. Seven principles; localStorage flagged as fragile under cookie clearing. https://www.inkandswitch.com/essay/local-first/.

Authoritative engineering voices

• Archibald, J. idb README and source. https://github.com/jakearchibald/idb/blob/main/README.md.
• Archibald, J. idb-keyval README. https://github.com/jakearchibald/idb-keyval/blob/main/README.md.
• Fahlander, D. Dexie.js documentation. Performance. https://dexie.org/docs/Performance.
• Fahlander, D. Dexie.js documentation. Yet Another Indexed DB Library? https://dexie.org/docs/IndexedDB-related-pages.
• Steiner, T. (Chromium engineer) — IndexedDB Snappy compression work. https://developer.chrome.com/docs/chromium/indexeddb-storage-improvements.
• LePage, P. Storage for the web (cited above). https://web.dev/articles/storage-for-the-web.
• LePage, P. Persistent storage (cited above). https://web.dev/articles/persistent-storage.
• Wilander, J. Full Third-Party Cookie Blocking and More (cited above). https://webkit.org/blog/10058/.
• van Kesteren, A. (editor). Storage Standard (cited above). https://storage.spec.whatwg.org/.
• Surma. Architecting web apps (Chrome Dev Summit) — main-thread cost framing for IndexedDB. https://chromeos.dev/.

Community / additional context

• HN. Show HN: Obsidian — A knowledge base that works on local Markdown files. 1,087 points, May 2020. https://news.ycombinator.com/item?id=23324598.
• HN. Why IndexedDB is slow and what to use instead (rxdb discussion). https://news.ycombinator.com/item?id=29314766.
• Reddit. r/webdev top-rated threads on IndexedDB vs localStorage architecture choice.
• Reddit. r/javascript discussions on Dexie vs raw IDB vs localForage choice.
• Reddit. r/PWA threads on Safari seven-day eviction and persistence prompts.