When is cursor-based pagination a better choice than page-number pagination for infinite scroll?

Why cursor-based pagination fits changing infinite-scroll lists

Cursor pagination is the better choice when the list is volatile, because it anchors the next request to a known item instead of a shifting page boundary. For infinite scroll, that makes the user experience more stable: the same item is less likely to appear twice or disappear between fetches as new content arrives or older content is removed.

That stability matters most when the dataset is ordered by recency or another live signal, such as feeds, notifications, activity logs, search results, or timelines. In those cases, page-number pagination assumes the list is static enough that page 3 today is still page 3 a moment later, which is often untrue once the stream is actively changing.

Cursor pagination also aligns better with how infinite scroll behaves in practice. The client is asking for the next slice of items after the last item it has already rendered, so the backend can return a continuous sequence without relying on an offset that may have drifted. That usually produces fewer gaps, less duplication, and a smoother scroll experience under concurrent writes.

Where page numbers break down under live updates

Page-number pagination is most fragile when inserts or deletes happen between requests. A new item at the top can push every later item down a slot, which changes the meaning of page 2, page 3, and so on. If the user has already scrolled partway through the list, that shift can cause the client to skip records or fetch the same records again.

Offset-style page navigation is also awkward when the user is not actually jumping between discrete pages. Infinite scroll implies continuity, not page boundaries, so the page-number model tends to leak implementation details into the user experience. Cursor-based pagination keeps the request model closer to the interaction model, which is why it usually feels more reliable in a feed-like UI.

That said, page-number pagination can still be useful for stable, archival, or human-browsable collections where users need direct random access to a specific page. The key question is whether the list is expected to stay effectively fixed during the session. If it is not, cursors generally produce a safer and more predictable result.

Choosing cursors without overcomplicating the API

The main design decision is what the cursor represents. In most systems it should be derived from an ordered, unique record position, such as the last item returned, so the next request can resume from that exact point. The ordering key must be consistent enough that the backend can reproduce the same sequence even when the table itself is changing.

Cursor pagination works best when the sort order is deterministic and the backend can guarantee a stable tie-breaker. If multiple records can share the same primary sort value, such as identical timestamps, the cursor should include enough information to continue unambiguously. Without that, the API can still drift even if it nominally uses cursors.

For infinite scroll, the practical goal is not just efficiency, but continuity. A well-designed cursor endpoint should let the client append the next batch without reshuffling what is already on screen. That is the real advantage over page numbers: the user experiences one moving list, while the server preserves a reliable fetch position underneath it.

Practitioner Guidance

What to verify: Confirm that the sort order is stable enough to resume from a cursor without ambiguity, and that the cursor contains enough state to disambiguate ties. If your ordering can change between requests, test for duplicates and missed items under concurrent inserts and deletes.

Decision rule: Use cursor pagination for live, append-only, or frequently changing feeds where continuity matters more than direct page jumps. Keep page-number pagination only when users genuinely need random page access and the dataset is unlikely to shift during the session.

Practitioner takeaway: Infinite scroll is usually a continuity problem, not a page-navigation problem, so the pagination scheme should preserve sequence stability first and UI convenience second.

Related resources from NHI Mgmt Group

• How should security teams implement cursor based pagination in SCIM when directory syncs get large?
• What is the difference between cursor-based pagination and AsyncSequence pagination in server-side Swift?
• When does OIDC federation work better than a vault-based approach?
• When does policy-based access control become better than role-based access control?