---
title: 'Cursor Pagination'
source: 'https://youtube.com/watch?v=9HDu7pizcs8'
video_id: '9HDu7pizcs8'
date: 2026-08-04
duration_sec: 81
---

# Cursor Pagination

> Source: [Cursor Pagination](https://youtube.com/watch?v=9HDu7pizcs8)

## Summary

This video explains the difference between offset and cursor-based pagination, highlighting the problems of offset pagination at scale and how cursor pagination solves them. It uses a real-world example of duplicate posts to illustrate the issues and provides a clear recommendation for production systems.

### Key Points

- **Offset pagination problem** [00:01] — Offset pagination (e.g., LIMIT 10 OFFSET 1000) skips N rows, but the database still scans every skipped row, causing performance degradation at scale.
- **Duplicate posts bug** [00:28] — When new posts are inserted while a user scrolls, rows shift, causing the same post to appear on multiple pages. Deletions can also cause posts to be skipped entirely.
- **Cursor pagination solution** [00:42] — Cursor pagination uses a cursor (timestamp or ID) to fetch items after a specific point, avoiding scans and shifting issues.
- **Index seek efficiency** [00:55] — Cursor pagination uses an index seek to jump directly to the position on disk, eliminating the need to scan and skip rows.
- **Recommendation** [01:09] — Offset pagination is fine for admin dashboards or small scale, but cursor-based pagination is non-negotiable for feeds with real traffic.

### Conclusion

Cursor-based pagination is essential for scalable, reliable APIs, preventing duplicate or missing items and improving performance.

## Transcript

testing, but then in your production and users started to see duplicate posts. Why? Well, you were using what's called offset pagination. A query like limit offset pagination. A query like limit 10, offset by 1,000. It skips N rows and
simple and it's the default for most systems, but it has two big problems at scale. First, the database still scans every skipped row. At offset 500,000, you're throwing away half a million rows on every request. Second, this is where
our duplicate bug came in. If a new post gets inserted while a user is scrolling, every row shifts down by one. So, the post that was at position 10 is now at position 11. Next page starts at offset 10 and you've served them the same post
again. Or, if a row got deleted and you end up skipping one entirely. Cursor pagination fixes both of these issues. Instead of skip N rows, you say, "Give me everything after this item." Usually using the timestamp or the ID from the
last item the client saw. So, the query becomes something more like this. The index seeks straight to the spot on disk, no scans, no shifting, and no fine for admin dashboards or small scale, but for any feed with real
traffic, cursor-based pagination is a non-negotiable. Check out our full breakdown of pagination and API design over at hellonext.com.