The next page, without OFFSET

Constraints

1. 1No OFFSET. The whole point is that the query does not count through skipped rows.
2. 2Same order as before: delivered_on descending, then delivery_id descending.
3. 3The cursor comparison must match that ordering exactly. Comparing on the date alone would skip the four rows that share 2026-03-04 with the cursor row, and comparing on the id alone would return rows from the wrong day.
4. 4'After' means strictly after: the cursor row itself must not come back, or it appears on two pages.
5. 5Five rows, same four columns as page 2.

Worked example

The cursor is (2026-03-04, 25). Everything on an earlier date qualifies immediately. Within 2026-03-04 itself, only the rows with a smaller id qualify — 24, 16, 8 and 7 — because the sort puts higher ids first. That is the whole predicate: delivered_on < cursor_date OR (delivered_on = cursor_date AND delivery_id < cursor_id). The strict < on the second branch is what stops delivery 25 returning on its own next page. The result is identical to LIMIT 5 OFFSET 5 — five rows starting at delivery 24 — but the engine can seek straight to the cursor on an index of (delivered_on, delivery_id) instead of walking the rows above it.

What this tests

Whether you can translate a sort order into a cursor predicate — the part people get wrong, usually by comparing on only one of the two sort keys.