The slow page problem
OFFSET-based pagination is fine for the first 10 pages. By page 1000, you're asking the database to scan and discard 10,000 rows on every request. The latency creeps up linearly with offset. Eventually the user clicks page 100 and it takes 8 seconds.
Keyset pagination — constant cost
Instead of "page N", remember the last (sort_value, id) seen and ask "next 20 after this". The query uses an index range scan: WHERE (created_at, id) < (last_seen_created_at, last_seen_id) ORDER BY created_at DESC, id DESC LIMIT 20. Constant cost regardless of page depth.
Trade-offs
Keyset pagination is forward-only by default — no jumping to "page 50". You can support back-and-forth with two cursors. URLs become opaque (cursor strings instead of ?page=N). For most "infinite scroll" UIs, that's fine — page numbers were a UX concession to OFFSET, not a user need.