Offset-Based Pagination

Offset pagination uses a page position and page size.

For example:

users(limit: 20, offset: 40)

This means the client wants up to 20 users after skipping the first 40 records.

In MongoDB, the conceptual query might be:

UserModel
  .find(filter)
  .sort({ createdAt: -1 })
  .skip(offset)
  .limit(limit);

Offset pagination is easy to understand and works well for many administrative interfaces and relatively small datasets.

However, large offsets can become expensive because the database may need to walk past many records before producing the requested page.

There is also a consistency problem when records are inserted or deleted between requests.

Imagine:

Request 1 → offset 0
New record inserted
Request 2 → offset 20

The position of records can shift, potentially causing duplicates or skipped items.

A stable sort order is therefore important even with offset pagination.

Offset pagination is not inherently bad. It is a useful technique when its trade-offs match the workload.

Offset Pagination
Simple: Easy page/offset model
Clients can reason about page numbers and offsets easily.
Large offsets: Potentially expensive
The database may need to traverse many records before reaching the offset.
Changing data: Can shift page boundaries
Inserts and deletes between requests can cause duplicates or skipped records.
Key Takeaways
  • Offset pagination is simple and useful for many use cases.
  • Large offsets can become expensive.
  • Changing datasets can shift page boundaries.
  • A deterministic sort order should accompany pagination.
Knowledge Check

What is a common weakness of offset pagination on frequently changing datasets?