- IndexedDB
-
Browser API for large, structured, origin-scoped data stored
asynchronously in the client. Not a SQL database; records live in
object stores and are accessed by key (and optional indexes).
- Origin-scoped
-
Storage is isolated to a site origin (scheme + host + port). Other
origins cannot read your IndexedDB data.
- Client storage
-
Data kept in the browser (or device) for an origin — not the same as
“source of truth on the server.” Includes memory, web storage, Cache
API, OPFS, IndexedDB, cookies, etc.
- Web Storage
-
Collective name for
localStorage and
sessionStorage: synchronous string key/value maps with
small practical limits. Not the same API as IndexedDB.
- localStorage
-
Persistent (until cleared) Web Storage for string key/values. Synchronous
on the main thread; ~few MB; not available in workers. Prefer avoiding
for bulk or structured app data.
- sessionStorage
-
Tab-lifetime Web Storage for string key/values. Same sync/size limits
as localStorage; not shared across tabs or workers.
- Cache Storage API (Cache API)
-
Store for Request/Response pairs — typically HTTP assets and
offline shells. Best for “network resources to load the app,” not
arbitrary structured records (that’s IndexedDB).
- Origin Private File System (OPFS)
-
Origin-scoped file-system-like storage for file-shaped content. Prefer
when the data model is files/bytes more than keyed records.
- Cookies (as storage)
-
Small name/value data sent on HTTP requests. Fine for session tokens
in limited cases; wrong tool for bulk client storage (bloats every
request; not for workers as a store).
- Quota
-
How much an origin may store. Browser- and device-dependent; often
large (hundreds of MB+) for IndexedDB/Cache, not a fixed 5 MB like
Web Storage folklore.
- Eviction
-
Browser may delete site data under storage pressure (best-effort
storage) or policy (e.g. Safari inactivity caps). Durable forever is
never a safe default assumption.
- Database
-
Named, origin-scoped repository with a single current integer version
and zero or more object stores.
- Connection
-
Result of
indexedDB.open: script’s handle to a database.
Many connections (tabs/workers) may exist at once.
- Object store
-
A named bucket of records inside an IndexedDB database (roughly
“table-shaped,” but values need not share one schema). Created or
deleted only during upgrade.
- Transaction
-
Atomic unit of IndexedDB work: a group of reads/writes that all
commit or all abort. All IDB operations run inside a transaction.
Scoped to named object stores and a mode
(
readonly / readwrite /
versionchange). Auto-commits when finished; not a
long-lived handle across arbitrary await.
- put
-
Store method that inserts or overwrites a record for a key (upsert).
- add
-
Store method that inserts only; fails if the key already exists.
- upgradeneeded
-
Event on the open request when the requested version is higher than
the existing database (or the DB is new). Only place for schema
changes (stores/indexes).
- versionchange
-
Event fired on open connections when another client wants to upgrade
or delete the database. Handlers should close so the upgrade can
proceed.
- blocked
-
Event on the open request when other connections have not closed after
versionchange, so the upgrade cannot start yet.
- In-line key
-
Primary key taken from a property on the stored value via
keyPath.
- Out-of-line key
-
Primary key supplied separately from the value (no keyPath on the
store).
- Key generator (autoIncrement)
-
Store option that generates monotonic numeric keys when you do not
supply one.
- Index
-
Secondary lookup structure on an object store, defined at upgrade
time, for querying by a property other than the primary key. Options
include
unique and multiEntry. Write path
and schema cost — not free ad-hoc SQL.
- Key range (IDBKeyRange)
-
Ordered range of keys for queries and cursors:
only, lowerBound, upperBound,
bound.
- Cursor
-
Iterator over records (or keys) matching a range. Streams results one
at a time via
continue() — prefer over dumping huge
getAll sets into memory.