Sort

Each 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

Pages count from 1. The default size is 20; the server caps it at 200. 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.
The response keeps its shape: { "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 on total, 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, then id).
  • 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:
Pass the last item’s 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.