Skip to content

Mit Keyset- (Seek-) statt OFFSET paginieren snippet

OFFSET-Paginierung geht auf jeder Seite N Zeilen vorbei — Seite 1000 liest 999 Seiten an Daten erneut, und jedes Einfügen zwischen zwei Anfragen verschiebt Zeilen, sodass Einträge doppelt erscheinen oder verschwinden.

OFFSET-Paginierung geht auf jeder Seite N Zeilen vorbei — Seite 1000 liest 999 Seiten an Daten erneut, und jedes Einfügen zwischen zwei Anfragen verschiebt Zeilen, sodass Einträge doppelt erscheinen oder verschwinden. Keyset- (Seek-)Paginierung fragt stattdessen: gib die Zeilen strikt nach der letzten, die ich gesehen habe. Der Sortierschlüssel muss eindeutig und stabil sein — ein Zeitstempel allein ist es nicht, gleichrangige Zeilen ordnen sich unvorhersehbar um —, deshalb reitet die id als Tiebreaker mit, und der zusammengesetzte (created_at, id)-Index bedient den Scan. Die Zeilenvergleichs-Syntax (a, b) > (x, y) ist die prägnante Postgres-Schreibweise.

Runnable recipe · 1 languages
Files & Datasqlpaginationkeysetseekperformance

Every language

1 languages, copy-ready. One at a time with syntax highlighting, or all inline.

SQLSQLrunnable
-- page 1
SELECT id, created_at, title
FROM posts
ORDER BY created_at DESC, id DESC
LIMIT 20;

-- next page: feed the LAST row's keys back in
SELECT id, created_at, title
FROM posts
WHERE (created_at, id) < ('2026-08-24 18:02:00+00', 9014)
ORDER BY created_at DESC, id DESC
LIMIT 20;

The tuple comparison (created_at, id) < (last_seen_at, last_seen_id) is lexicographic — exactly the ORDER BY in reverse. Needs the composite index CREATE INDEX ON posts (created_at DESC, id DESC) to stay an index scan at depth. Run both queries in the playground.

Run in the SQL playground →

Keep going

Read the sql-indexing cheatsheet →