IndexedDB

In this chapter

We'll meet IndexedDB from scratch — object stores, keys and indexes, the real asynchronous and transactional model, versioning via onupgradeneeded, and real scale (hundreds of MB+) — as the real browser mechanism that makes an offline-browsable product catalog buildable.

10–12 min

The Problem in Real Life

Mike has a new idea, bigger than the cart. "What if the app worked at all when a customer loses signal — mid-aisle, weak wifi, whatever. Could they still browse what we already showed them?"

Sarah nods. "That's a real, different problem. localStorage tops out around 5-10MB, and it's string-only — a real product catalog needs more room than that, and real structure. There's exactly one browser API built for this."

Could someone keep browsing what we already loaded, even offline?

Mike

A Key-Value String Store vs. a Real Structured Database

Real structured objects, real indexes

Object stores hold real JavaScript objects with real indexes for fast lookup — genuinely database-shaped, not a flat key-value string store.

Asynchronous and transactional, on purpose

Every operation is async and wrapped in a transaction — a deliberate design choice for a database that can hold hundreds of megabytes without freezing the page.

IndexedDB is a real, transactional, structured database built into the browser — genuinely closer to a NoSQL document database than to localStorage's simple string store. It stores real JavaScript objects, supports real indexes for fast lookup, and holds far more data than localStorage ever could.

Object stores, not tables — but the same real idea. IndexedDB organizes data into object stores (roughly equivalent to a table), each holding real JavaScript objects, each identified by a key — either a value you provide explicitly, or an auto-incrementing number IndexedDB generates itself. Unlike localStorage, values are stored as real structured data, not strings — no manual JSON.stringify() required.
Indexes make real, fast lookups possible. Beyond the primary key, an object store can define indexes on other fields — so a real catalog could be looked up by product ID (the key) or searched by category (an index), both fast, without scanning every record. This is genuinely database-shaped thinking, applied inside the browser.
Asynchronous, and genuinely transactional. Every real operation happens inside a transaction, and every operation is asynchronous — it doesn't block the page the way localStorage does, using events (or, in modern code, wrapped in promises) to signal completion. This is a real, deliberate design choice: a database holding potentially hundreds of megabytes cannot afford to freeze the page on every read.
Versioning, the real mechanism for schema change. An IndexedDB database has a real version number, and creating or changing an object store's structure only happens inside a special onupgradeneeded event, triggered when a page opens the database at a higher version number than what's currently stored. This is IndexedDB's own real answer to "how do you change the shape of data already saved on someone's device" — a genuinely important, easy-to-miss detail for anyone shipping real, evolving offline data.
Real scale — hundreds of megabytes, sometimes more. Where localStorage caps out around 5-10MB, IndexedDB's real limit is typically a meaningful percentage of available disk space, often hundreds of megabytes to low gigabytes depending on the browser and available storage — genuinely enough room for Mike's real idea: a full, offline-browsable product catalog, cached on the customer's own device.

IndexedDB is real, honest overhead compared to localStorage's one-line setItem — more concepts, more real setup code, a genuinely steeper start. That overhead buys real capability: structured objects, fast indexed lookup, and enough real capacity for Mike's actual idea, offline browsing, to genuinely work.

Key Takeaway

IndexedDB isn't "localStorage but bigger" — it's a genuinely different kind of tool, a real transactional database living inside the browser, and it's the only browser storage mechanism in this Act built to hold GreenMart's entire catalog at real scale.

Why This Matters

Mike's idea — browsing the catalog while offline — is genuinely impossible with localStorage alone, both because of the size limit and because a catalog is real structured data, not a handful of strings. IndexedDB is the real, specific mechanism that makes the idea buildable at all.

GreenMart now has the real browser database this course keeps building toward — structured, indexed, asynchronous, and genuinely large enough for a real product catalog. The next chapter meets a different, complementary mechanism: one built specifically to cache real HTTP responses, not application data — the Cache API.