IndexedDB getAllRecords()

IndexedDB getAllRecords()

A lot of IndexedDB code is noisy because you often need the value, the primary key, and sometimes the index key together. getAllRecords() collapses that common pattern into one call, which is exactly the kind of ergonomics win Interop 2026 should deliver.

const tx = db.transaction('messages');
const store = tx.objectStore('messages');
const records = await store.index('by-room').getAllRecords(
  IDBKeyRange.only(roomId),
  100,
);

for (const { key, primaryKey, value } of records) {
  renderMessage(primaryKey, value);
}

Why It Is Better Than getAll() Plus getAllKeys()

The old pattern forced you to make two reads and zip the results back together, or drop down to a cursor just to keep keys and values aligned. getAllRecords() keeps the payload together and makes batching logic far easier to audit.

Where It Fits

Use it for list screens, sync queues, local search results, and paged offline views where you need multiple records at once. If you truly need streaming iteration, write-time mutation, or very large scans, a cursor is still the better primitive.

Fallback Story

Feature-detect the method and keep the old paired-read or cursor path available. That lets you ship a smaller code path in modern browsers without pretending older engines have the same ergonomics yet.

Design Guidance

Even with nicer reads, IndexedDB rewards disciplined schema ownership. Keep key paths explicit, centralize upgrade code, and treat local storage shape as an API you version deliberately.

---