The offset trap
The obvious way to page is offset and limit, such as skip nine thousand and take ten. In a sharded engine this is brutal. To return results nine thousand to nine thousand ten, each shard must produce its top nine thousand ten, ship them to the coordinator, which then sorts and discards almost all of them. Cost grows with the offset, so deep pages get slower and use more memory.
Search after with a cursor
The efficient alternative is a cursor. Instead of an offset, the client passes the sort values of the last item from the previous page. Each shard then resumes precisely after that point, returning the next page without rebuilding everything before it.
- This makes paging cost constant regardless of depth.
- It requires a total order, so the sort must include a tie breaker like a unique id.
- The cost is that you cannot jump to an arbitrary page number; you only walk forward.
For point in time consistency across pages, engines pin a snapshot so new writes do not shift results mid scroll.
Key idea
Deep offset paging forces every shard to fetch and discard huge prefixes, so use a cursor that resumes after the last sort values for constant cost forward paging.