Sort
order after the first breaks ties in the earlier ones. Ascending is the default. Without any order, the order is not guaranteed; always sort lists you show.
Page size and number
limit(n) asks for at most n records.
Turn paging off
Lists are paged by default. When you want every match in one response (a short dropdown, a small lookup table), ask for it.{ "data": [...], "page": null, "per_page": null, "total": 42 }. page and per_page are ignored when paginate=false. One response holds at most 5000 records. If more match, the server answers 400 rather than quietly cutting the list short, so narrow it with filters or go back to paging. For large tables, walk through everything instead.
Load more
Keep the page number and add results as it grows. Stop when a page comes back short; don’t rely ontotal, which can be null.
Page controls (when total is a number)
Walk through everything
For exports and background work, iterate instead of loading one huge page:pages yields one page at a time, so memory stays flat.
Stable pages
If records arrive while someone is paging, items shift between pages. For feeds:- Sort by something steady (
created_at, thenid). - Prefer “load newer” with a filter (
gt("created_at", lastSeen)) over page numbers. - Let realtime add new records at the top instead of re-reading page 1.
Keyset-style paging
For very large tables, “give me 20 older than this” is faster than deep page numbers, because the database doesn’t count skipped rows:created_at as the next cursor. Make sure created_at is indexed.
Read records
All the ways to read.
Live records
New rows as they arrive.