A user reads the first ten records, requests the next page and sees one record again. The query may be working exactly as written. If the dataset changed between requests, an offset can now point to a different boundary.
PostgreSQL’s LIMIT and OFFSET documentation emphasises predictable ordering when selecting subsets. A stable order is necessary, but separate requests can still observe different data when rows are inserted, removed or updated.
Walk through a small example
Suppose records are ordered newest first. Page one returns the first ten. Before page two is requested with an offset of ten, a new record is inserted at the front. The old tenth record has shifted to the eleventh position and can appear again.
A deletion before the boundary can create the opposite effect: an unseen record shifts into the skipped range. This is a consequence of counting positions in a changing list.
Define the experience you need
For browsing a live feed, cursor-based pagination can continue from a known ordering key rather than a count. Use a deterministic ordering with a tie-breaker, and define how updates to the ordering fields behave. A cursor is not automatically a frozen snapshot.
For an export or audit that must represent one consistent dataset, consider an appropriate snapshot or materialised selection. The implementation depends on the database and transaction model; a web page’s next-button token alone does not provide that guarantee.
Test with insertions, deletions and equal sort values between requests. Record whether duplicate or missing records are acceptable for the product’s purpose. Offset pagination may remain perfectly suitable for a small stable list. The important decision is to make its behaviour under change explicit rather than discovering it through a customer’s repeated row.