List endpoints that return everything
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
}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.
- Open your app's main list page in Chrome, press F12, choose the Network tab, filter by "Fetch/XHR" and reload.
- 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.
- Open the Headers tab and look at the request for a page or range parameter (Supabase requests carry a
Rangeheader orlimitandoffsetin 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).
Related patterns
- Whole table downloaded, filtered in the browserPerformanceMedium
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.
- One database query per list itemPerformanceMedium
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.
- No index on the columns you filter byPerformanceMedium
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.
- Unbounded input length to the modelAI featuresMedium
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.
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.