To examine this, consider a PostgreSQL table containing 30 million records, ordered by descending primary-key ID, with 100 records per page.

1. When OFFSET becomes expensive

The conventional approach is straightforward:

SELECT *
FROM sample
ORDER BY id DESC
LIMIT 100 OFFSET 1000000;

However, an index does not allow PostgreSQL to jump directly to the millionth position. It still needs to advance through the preceding entries.

Local measurements using EXPLAIN ANALYZE showed:

Retrieving just 100 records at OFFSET 20 million took approximately 4.66 seconds.

Beyond latency, unrestricted deep-page requests can also create unnecessary database pressure under concurrent traffic.

Can we avoid scanning the skipped records?

2. Cursor-based pagination

What if we navigate through the pages sequentially? Instead of using an OFFSET, we can pass the ID of the last record retrieved on page N as a cursor when requesting page N + 1.

Using this ID in a WHERE clause allows PostgreSQL to seek directly to the relevant position through the index, avoiding the need to scan through records from previous pages.

SELECT *
FROM sample
WHERE id < :last_seen_id
ORDER BY id DESC
LIMIT 100;

This is keyset pagination, commonly implemented using cursors.

PostgreSQL can seek toward the supplied ID rather than traversing millions of preceding entries.

In the experiments, all tested indexed-boundary queries executed in under 10 ms, even at deep positions.

The improvement is substantial, but these measurements assume the boundary ID is already known.

What if a user wants to jump directly from page 5 to page 100,000?

A cursor identifies where to continue, not the starting record of an arbitrary page.

Finding that boundary remains a challenge.

3. Sparse positional anchors

We can limit the number of records PostgreSQL needs to skip by introducing an upper bound on OFFSET. Suppose we maintain a separate table that stores the ID of every 10,000th record. We call each of these stored reference points an anchor.

When retrieving a page, we first find the nearest anchor whose stored position does not exceed the requested OFFSET. We then use its ID to seek to that position and scan only the remaining records to reach the requested page.

For 30 million records, this requires approximately 3,000 anchors.

To retrieve records at OFFSET 10,005,500:

1. Find the anchor at position 10,000,000.

2. Seek to its ID using the primary-key index.

3. Skip the remaining 5,500 records.

This bounds the local OFFSET to fewer than 10,000 entries.

The anchor-assisted retrieval experiments were encouraging: all tested queries executed in under 10 ms, including requests targeting positions millions of records into the dataset.

However, generating the initial 3,000 anchors required numbering 30 million records and took approximately 10.96 seconds.

More importantly, anchors introduce another problem.

4. What happens when records change?

Anchors represent positions, not just IDs.

When a new record is inserted, existing records shift one position deeper. Potentially all 3,000 anchors need updating.

An incremental update experiment completed in under 100 ms, substantially cheaper than rebuilding the entire anchor table but still potentially expensive for frequent writes.

Deletions shift positions in the opposite direction. Batch operations complicate maintenance further.

Thus, optimizing deep reads introduces write amplification and consistency challenges.

5. A practical trade-off

For read-heavy applications, exact anchor maintenance may be unnecessary.

One option is to refresh anchors periodically, while accepting temporary positional drift.

For example, inserting 20,000 records at the beginning shifts an existing anchor by approximately 20,000 positions.

Deep-page results may therefore become inaccurate until the next refresh. The positional drift can cause deep-page requests to return overlapping or skipped records relative to their intended page boundaries.

Whether that is acceptable depends on the product.

A hybrid strategy could use cursor pagination for sequential navigation, OFFSET for shallow jumps, and sparse anchors for deep jumps.

The refresh interval and switching threshold should be determined through workload measurements.

Conclusion

OFFSET provides simplicity, cursors provide efficient sequential traversal, and sparse anchors enable faster deep jumps.

But every optimization introduces trade-offs involving maintenance, consistency, or complexity.

The objective is not to find the fastest individual query, but to choose a pagination strategy whose overall costs match the application's requirements.

Further Reading & Acknowledgments

For a deeper exploration of PostgreSQL pagination strategies, I recommend Joe Nelson's excellent article, Five Ways to Paginate in PostgreSQL.

His discussion of keyset pagination and approximate random access offers valuable perspectives on the trade-offs explored in this article.

Benchmark disclaimer: These experiments were conducted locally on a 30-million-row PostgreSQL dataset, with other applications running in the background. The environment wasn't isolated or optimised for benchmarking, so don't take the exact timings too seriously. The numbers are intended to illustrate relative performance trends, not establish reproducible performance guarantees.