How can I use IDBKeyRange bounds with IDBCursor to paginate a Firefox IndexedDB object store without rescanning the entire dataset?

Direct answer

Use a one‑sided IDBKeyRange.lowerBound that starts just after the last key you returned, open a forward‑only cursor (direction: 'next') inside a readonly transaction, collect the needed number of records, then remember the key of the last record. For the next page open a new cursor with IDBKeyRange.lowerBound(lastKey, false) (exclusive) to skip that key and continue from the next record.

Why this works (confirmed facts)

• IDBKeyRange.lowerBound(key, inclusive) positions the cursor at the first record whose key is ≥ key (if inclusive) or > key (if exclusive).
• IDBCursor.continue([key]) advances the iterator from its current position; supplying the last seen key resumes iteration exactly after that record.
• Each IndexedDB transaction provides a snapshot of the database at the moment the transaction starts, so within a single transaction the cursor will not see concurrent changes.

Steps for this case

1. Start a readonly transaction on the object store.
2. If this is the first page, open the cursor with no range (or IDBKeyRange.lowerBound(0, true) for numeric keys). For subsequent pages, pass the exclusive lower bound: IDBKeyRange.lowerBound(lastKey, false).
3. Open the cursor: store.openCursor(range, 'next').
4. In the cursor’s success handler, collect records until you have the desired page size.
5. When you have enough records (or the cursor ends), record the key of the last returned record as lastKey.
6. Close the transaction and return the collected page to the UI.
7. Repeat from step 1 for the next page, using the stored lastKey to build the new range.

Stable snapshot considerations

IndexedDB only guarantees transaction‑local snapshots. Because a transaction automatically commits when the micro‑task queue empties, you cannot keep a single transaction open across UI‑driven page requests. Consequently:

• Inserts that occur between pages will appear in later pages if their key falls after the current lastKey.
• Deletes between pages simply cause the cursor to skip those keys; no record is returned twice.
• If you need a truly immutable view across pages, you must either (a) fetch and cache the key list up front, or (b) add a monotonic version column and filter by a version snapshot.

Missing diagnostic detail

Do you have a unique, monotonically increasing key (primary key or a unique index) that you can use as the pagination boundary? If the store only has non‑unique keys, the lower‑bound/exclusive technique may skip or duplicate records, and you would need to create a unique index or compound key before applying the method above.

// Example: fetch one page
function getPage(store, pageSize, lastKey) {
  return new Promise((resolve, reject) => {
    const tx = store.transaction(store.name, 'readonly');
    const range = lastKey === undefined ? undefined : IDBKeyRange.lowerBound(lastKey, false);
    const cursorReq = tx.objectStore(store.name).openCursor(range, 'next');
    const page = [];
    cursorReq.onsuccess = e => {
      const cursor = e.target.result;
      if (!cursor) { resolve(page); return; }
      page.push(cursor.value);
      if (page.length >= pageSize) {
        // remember key for next page
        lastKey = cursor.key;
        resolve({ page, lastKey });
        return;
      }
      cursor.continue();
    };
    cursorReq.onerror = e => reject(e.target.error);
  });
}