It returned three. The integration test had seeded five suppression rows in beforeAll , called GET /api/suppressions?limit=2 , and walked the cursors forward expecting all five back. The first page returned two. The second page returned one. The third page came back empty. The suppression list endpoint is a paginated GET . Tenants call it to see who they have manually blocked, who Resend marked as a hard bounce, and who complained about an email. The list grows over time and needs ordering by recency. Standard cursor pagination: order by (created_at DESC, id DESC) , encode the last-seen tuple into a base64 cursor, and the next page asks for everything strictly less than that tuple. I had this pattern working on the notifications endpoint and wrote the suppressions version against the same template. Drizzle, Postgres, tuple comparison in SQL. Where the Microseconds Disappeared The seed used a single db.insert(...).values([row1, row2, row3, row4, row5]) call. Postgres performs that as one transaction.…