An IndexedDB store holds 200,000 orders with an index on their timestamp, and you need the 50 most recent. How do cursors and IDBKeyRange let you read that without pulling the whole store into memory?

## Two ways to read a range IndexedDB gives you two shapes for reading more than one record, and the interview question is really about knowing when each is right. **`getAll(query, count)`** returns an array of every matching value in one request. It is concise, and because it costs one request rather than one event per record, it is usually the faster of the two for modest result sets. Its costs are that the entire array is built in memory before your callback runs, and that results always come back in ascending key order — there is no direction argument. **`openCursor(query, direction)`** returns an iterator. Its `success` event fires once per matching record with a cursor object; you take what you need and call `continue()` to get the next one. Memory stays proportional to what you retain, you can stop at any point, you can choose descending order, and in a `readwrite` transaction you can mutate the record you are standing on. ## The newest-fifty problem ```js const tx = db.transaction('orders', 'readonly'); const index = tx.objectStore('orders').index('byCreatedAt'); const recent = []; index.openCursor(null, 'prev').onsuccess = (event) => { const cursor = event.target.result; if (!cursor || recent.length === 50) return; // stop: no continue() recent.push(cursor.value); cursor.continue(); }; tx.oncomplete = () => render(recent); ``` The `'prev'` direction is what makes this cheap. Because the index is sorted by timestamp, descending iteration starts at the newest record, so the fifty you want are the first fifty visited. `getAll` cannot express this: it would return the *oldest* fifty, and getting the newest that way means reading all 200,000 and slicing — which is exactly the memory blow-up you were asked to avoid. Ending the walk is done by omission. The cursor advances only when you call `continue()`; return without calling it and no further `success` events fire, the transaction has nothing pending, and it commits. ## IDBKeyRange A key range describes a contiguous span of the sorted key space, and every read method that accepts a key also accepts one — `get`, `getAll`, `getAllKeys`, `count`, `openCursor`, `openKeyCursor`, `delete`. - `IDBKeyRange.only(k)` — exactly one key. - `IDBKeyRange.lowerBound(k, open?)` — from `k` upward; pass `true` to exclude `k` itself. - `IDBKeyRange.upperBound(k, open?)` — up to `k`. - `IDBKeyRange.bound(lower, upper, lowerOpen?, upperOpen?)` — both ends, each independently inclusive or exclusive. ```js const september = IDBKeyRange.bound( new Date('2026-09-01'), new Date('2026-10-01'), false, true ); index.count(september).onsuccess = (e) => console.log(e.target.result); ``` The half-open form above — inclusive lower, exclusive upper — is the one to reach for on time ranges, because it makes consecutive months tile without overlapping. Note that `count()` with a range answers "how many" without transferring a single value, which is far cheaper than fetching to measure length. ## The cursor object On an index cursor, `cursor.key` is the *index* key, `cursor.primaryKey` is the store's primary key, and `cursor.value` is the record. `openKeyCursor` gives you a cursor with the two keys but no value, which avoids deserialising records you are only going to count or filter on key. Directions are `'next'`, `'prev'`, `'nextunique'`, and `'prevunique'`; the `unique` variants visit only the first record for each distinct index key, which is a cheap way to enumerate distinct values of an indexed field. `cursor.advance(n)` skips `n` positions in one step, and `cursor.continue(key)` jumps to a specific key. Naive pagination built on `advance(pageIndex * pageSize)` still walks the skipped entries, so deep pages get progressively slower; remembering the last seen key and starting the next page from `IDBKeyRange.lowerBound(lastKey, true)` is the version that stays flat. In a `readwrite` transaction, `cursor.update(newValue)` rewrites the record at the current position and `cursor.delete()` removes it — the standard way to run a bulk edit without loading everything first. ## Choosing between them Reach for `getAll(range, count)` when the result set is bounded and small and you want it ascending — it is less code and fewer event round trips. Reach for a cursor when the result set is large or unbounded, when you need descending order, when you want to stop early on a condition, or when you are editing as you scan. And remember the transaction rule that governs both: the cursor's `success` handler runs inside the transaction, so issuing the next request from there is legal, but leaving the walk to resume after a network call is not. ## What people get wrong Using `getAll()` with no range or count on a large store; expecting `getAll` to honour a direction; forgetting that not calling `continue()` is how you stop; confusing `cursor.key` with `cursor.primaryKey` on an index cursor; and paginating with `advance()` on deep pages instead of resuming from the last key.