How does Solr handle deep pagination, and why is cursorMark recommended over start/rows?

Standard pagination with start and rows looks simple - start=10000&rows=20 for page 501 - but internally Solr, like any Lucene-based system, still has to compute and rank the first 10,020 results and discard the first 10,000 just to return the requested 20. As start grows, this becomes increasingly expensive in both CPU and memory, and in a distributed SolrCloud collection every shard must independently compute up to start + rows results before the coordinator merges and trims them.

/select?q=*:*&sort=id+asc&cursorMark=*&rows=20

cursorMark avoids this by treating pagination as a stateful walk rather than a random-access offset. Instead of "skip N and take the next page," each response returns a nextCursorMark token encoding the sort values of the last document seen. The next request passes that token back, and Solr resumes exactly where it left off using an efficient index seek, with cost that stays roughly constant regardless of how deep into the result set you are.

The trade-off is that cursorMark requires a fully deterministic sort that includes the unique key as a tiebreaker (e.g. sort=score desc, id asc), and it only supports moving forward through results, not jumping to an arbitrary page number - which fits "infinite scroll" and export/crawl use cases better than a classic numbered page control.