Skip to content
BuildThenTestedSee packages

List endpoints that return everything

As the table grows, the response gets slower and heavier until it hits a platform body-size or time limit and the page simply stops loading, usually for your biggest customer first. How the app behaves when there is more data or more users. Check it yourself with the steps below; our test adds what a script and a second account can find.

What it looks like

// app/api/orders/route.ts
export async function GET() {
  const { data } = await supabase.from("orders").select("*");
  return Response.json(data); // every order, every column, every time
}
A list endpoint that returns the entire table on each call, with no page size, no cursor and no cap.

What happens

As the table grows, the response gets slower and heavier until it hits a platform body-size or time limit and the page simply stops loading, usually for your biggest customer first.

Where it shows up

Descriptive, not a verdict: builders and stacks whose defaults make this reachable, or that a public incident names. Each hub states the tool's own security features.

Check it yourself

Uses your builder's dashboard and your browser. No tools to install.

  1. Open your app's main list page in Chrome, press F12, choose the Network tab, filter by "Fetch/XHR" and reload.
  2. Click the largest request and check the Size column and the Response tab: count roughly how many items came back and compare with how many the screen shows.
  3. Open the Headers tab and look at the request for a page or range parameter (Supabase requests carry a Range header or limit and offset in the URL).

Bad result: the response holds every record in the table while the screen shows a few, there is no range or limit parameter, and the size grows every week. On Vercel a function response over 4.5 MB fails outright.

What we check

We seed list tables at several sizes and call each list endpoint directly, measuring payload size and response time and checking for a hard cap or a cursor. The report shows the size at which each endpoint would break the platform limit or time out.

Fix direction

Return one page at a time with a fixed maximum size, using range() or limit() in Supabase or a cursor on created_at and id, and have the UI ask for the next page. Set a server-side maximum so a client cannot request everything at once, and select only the columns the screen needs.

Mechanism documented in: Supabase JavaScript reference: range (verified 2026-09-21); Vercel Functions Limits (verified 2026-09-21).

Covered by

Full audit ($1,900, 5 business days)

Both include a re-check after your fixes.

Compare packages

Related patterns

  • Whole table downloaded, filtered in the browserPerformance

    Every user's device downloads far more than it shows, so pages slow down as the table grows, and if the database does not also restrict rows, other people's records land in the browser.

    Medium
  • One database query per list itemPerformance

    Pages that were fast with test data slow to a crawl as real data grows, the database handles hundreds of tiny queries per page view, and timeouts and higher hosting bills follow.

    Medium
  • No index on the columns you filter byPerformance

    Every message list, dashboard filter and row-level security check scans the full table, so pages slow down as data grows and the database CPU stays busy until queries start timing out.

    Medium
  • Unbounded input length to the modelAI features

    One oversized paste costs as much as thousands of normal requests, and a burst of them uses up your provider rate limit so real users see errors.

    Medium

Questions

how do i paginate results in supabase

Use range(from, to) on the query. Supabase's reference describes it as limiting the result by starting at an offset from and ending at the offset to, with both positions counted from zero and included. Combine it with order() so pages are stable, and fetch the next range when the user asks for more.

why does my list page stop loading when data grows

The endpoint behind it probably returns the whole table. Each week the response is a little bigger, until it crosses a platform limit on response size or time and fails. Check the Network tab: if the list request returns far more rows than the screen shows, add pagination.

what is the vercel response size limit

Vercel's function limits page states that the maximum payload size for a request or response body is 4.5 MB, and a larger payload returns an error. A list endpoint that returns a whole table will cross that line at some point. Pagination keeps each response small and predictable.

Back to the catalogue, or run the self-check for your stack.