How does Qdrant Scroll pagination avoid the main performance problem of large SQL OFFSET pagination?
Cursor-based traversal
Traditional SQL OFFSET pagination can become expensive at large offsets because the database may still need to locate or scan past a growing number of rows before returning the requested page. It also becomes unstable when records are inserted or deleted between requests unless ordering and isolation are carefully controlled.
Qdrant Scroll uses a continuation value, commonly represented by the last point ID or an equivalent offset returned by the API, so the next request can continue from the previous position rather than repeatedly asking the system to skip an ever-growing number of points.
The trade-off is that cursor-style pagination is designed for sequential traversal, not arbitrary page jumps. If a user needs page 37 directly, offset-style pagination can be conceptually simpler, but for large-scale data processing a continuation cursor is usually the better model.
A common mistake is assuming cursor pagination makes the entire traversal constant-time. Each batch still requires database work; the key benefit is avoiding repeated work proportional to the absolute page offset. Exact ordering and offset semantics should be checked for the Qdrant version in use.
- 1
Cursor continuation avoids repeatedly skipping all preceding records
- 2
Scroll is suited to sequential traversal of large collections
- 3
Cursor pagination is less suitable for arbitrary page-number jumps
- 4
Concurrent mutations require explicit consideration of traversal consistency
Scenario Questions
0-2 years experience
- 1Why can asking a database for page 100,000 using OFFSET be more expensive than asking for the first page?
- 2What does a cursor let the next request know that an offset does not express as directly?
2-5 years experience
- 1A migration takes hours and must resume from the last processed batch. Why is a continuation token useful?
- 2A developer wants random access to page 10,000 while also using Scroll. What limitation should you explain?
5-8 years experience
- 1A long-running traversal processes points while new points are continuously inserted. How would you prevent missed or repeatedly processed records?
- 2A scroll worker crashes after processing a batch but before recording its checkpoint. How would you make processing idempotent?
8+ years experience
- 1You need distributed traversal of billions of Qdrant points with restartability and exactly-once business effects. How would you partition work and manage continuation state?
- 2Your data-processing workload requires a consistent snapshot while production writes continue. What architectural mechanism would you need beyond simple cursor pagination?
Follow-up Questions
- What trade-off does cursor pagination have compared with page-number pagination?
- How would concurrent inserts affect a long-running scroll job?