How does Qdrant Scroll pagination avoid the main performance problem of large SQL OFFSET pagination?

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.