GraphQL Pagination — Cursor-Based vs Offset-Based

GraphQL list pagination comes down to a choice between stability and simplicity. Offset pagination is simpler to implement but produces incorrect results under concurrent data changes. Cursor-based pagination is more reliable and performs better at depth.

Why offset pagination fails in practice:

• With offset pagination, if a row is inserted between page fetches, the window shifts — users see duplicates or skip items entirely; for infinite-scroll UIs with concurrent data changes, this is a poor user experience
• The instability is invisible in testing because it only manifests with real concurrent data changes; most test scenarios use static datasets

Cursor-based pagination — how it works:

• Cursors anchor to the last seen sort key plus a unique tie-breaker like the primary key, so the next page is always consistent regardless of what was inserted or deleted between fetches
• On the database side, it translates to a keyset query — WHERE (created_at, id) > (?, ?) — which index-seeks directly to the right position; OFFSET 10000 forces the database to scan and discard ten thousand rows, growing slower as pages increase

Relay Connection pattern:

• The Relay Connection shape — edges, node, cursor, pageInfo with hasNextPage — is the standard that gives mobile and web clients one consistent pagination contract; it also provides room for edge-level metadata without breaking changes
• Cursors must include a unique tie-breaker — sorting by created_at alone produces non-deterministic results when rows share timestamps; compound (created_at, id) guarantees uniqueness

Spring Data caveat:

• Pageable in Spring Data always generates OFFSET SQL under the hood — for cursor pagination, write explicit @Query methods with keyset WHERE clauses

I recommend cursors for anything user-facing with concurrent data changes, and offset only for internal admin grids where page-jumping is a hard requirement and data consistency is lower priority.