Supabase hitting 100% usage, overlimit, and connection lost errors with only 5 active users (Next.js App Router)

[Princekrazio]

I am building a CRM application using Next.js 14 (App Router) and Supabase (SSR). Currently, we only have about 5 active users testing the application, but we are constantly hitting Supabase usage limits.

We are seeing the following errors in our logs:

Overlimit / 100% API usage
Connection lost / timeout errors
Supabase advertises supporting 50,000+ active users, so I am trying to figure out if there is an architectural flaw in my code that is causing an explosion of database requests.

Here is a breakdown of our current architecture and data-fetching strategy:

1. Next.js Middleware We have a middleware.ts file that protects our routes. It currently uses supabase.auth.getSession() on every request to verify the user's session before allowing access to the dashboard.

2. Background Polling (React Client Components) We have a few client components that use setInterval to keep data fresh while the user leaves the tab open:

A meeting reminder component that fetches the session, user profile, and upcoming meetings every 60 seconds.
A follow-up reminder component that fetches data every 5 minutes.
An auto-refresh component that triggers router.refresh() every 5 minutes, forcing the server components on the current page to re-fetch their data.
3. Supabase Realtime We have 4 different components establishing supabase.channel() connections to listen for live updates (notifications, leads, and leave approvals).

4. Data Fetching (N+1 queries) In several places, we are fetching a list of items (like tasks) and then fetching relations (like the assigned user's profile) in a loop, rather than using relational queries (e.g., select(", profiles()")).

My Questions:

Is calling getSession() in the middleware on every request (including static assets or API routes) enough to blow through the API limits for 5 users? Should I be using getUser() or handling this differently in the App Router?
How heavy is the penalty for using router.refresh() on an interval? Does this completely bypass the Next.js cache and hit the Supabase database directly every time?
Are the connection timeouts likely caused by the Realtime websockets, or by connection pool exhaustion from the background setInterval polling?
Any advice on which of these patterns is the biggest bottleneck and how to refactor them would be greatly appreciated!

[GaryAustin1]

You should be clear on what usage you are exceeding.
Take a look at the API Gateway info in Observability and logs for your high volume calls.
See https://supabase.com/docs/guides/auth/server-side/creating-a-client for use of getClaims/getUser/getSession .
NOTE getSession is NOT secure for what you are doing with it.

I don't use next.js but you should also be able to look at the API Gateway logs to see if your caching is working.

[luantaraschi]

Building on @GaryAustin1's point about identifying what you're actually exceeding, there's a premise here worth killing first, because it changes what you should go looking at.

There is no API request quota

The pricing page lists "Unlimited API requests" on all four plans, Free included. So "100% API usage" is not a billable meter you can exhaust, and no amount of getSession() calls will trip one.

Whatever is at 100% is one of the metered items on Manage your usage. For an app with 5 users and the architecture you describe, the realistic candidates are Egress (Free includes 5 GB) and Compute or Disk IO. Your "50,000+ active users" figure is the Free plan's Monthly Active Users allowance, which counts distinct auth identities per month. It says nothing about throughput, so it was never the right yardstick for this.

Gary's pointer to the API Gateway logs is the fastest way to settle it. Group by path: if /rest/v1/* dominates, this is your polling and N+1 queries, not auth.

Alongside that, in the SQL Editor:

select calls, mean_exec_time, total_exec_time, query
from pg_stat_statements
order by calls desc
limit 20;

Your N+1 profile lookups will sit at the top by calls, and that ordering answers your last question directly.

1. getSession() in middleware

It is not burning your quota, because it does not contact the Auth server. From Creating a Supabase client for SSR:

The session is loaded directly from local storage and isn't re-validated against the Auth server

It reads the cookies you handed the client and returns. A network call happens only when the token is near expiry and needs refreshing, so you get roughly one token refresh per user per token lifetime, not one per request.

Do not switch to getUser(). That is the opposite trade, same page:

makes a network call to the project's Auth instance to get the user record, which includes the most up-to-date information about the user at the cost of a network call

That genuinely would be one Auth request per middleware invocation.

Gary is right that getSession() is not safe for gating routes, and the fix for that is neither of the above:

Never trust supabase.auth.getSession() inside server code such as Proxy. It isn't guaranteed to revalidate the Auth token.

(The docs say "Proxy" because the file convention was renamed in Next.js 16. On your 14 it is middleware.ts.)

Use getClaims(), which gets you the security without the network cost:

reads the access token from storage and verifies it. Locally via the WebCrypto API and a cached JWKS endpoint when the project uses asymmetric signing keys (the default for new projects)

One condition attached to that: local verification only applies with asymmetric signing keys. On a legacy HS256 project, getClaims() falls back to calling getUser() to validate, and you are back to a network call per invocation. Check which your project uses before assuming the win.

Separately, and regardless of which method you pick: add a matcher so middleware stops running on assets.

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)'],
}

Without one, middleware runs on every static asset request, which is a real multiplier even when each invocation is cheap.

2. router.refresh() on a 5 minute timer

This is the heaviest of your three timers, and the penalty is worse than it looks.

router.refresh() re-executes the server components for the current route. Every Supabase query sitting behind those components runs again, so the cost is not one request but one request per query on the page. It also bypasses client-side caches by design, since re-fetching fresh server data is the entire point of the call.

Compounding it: reading cookies through @supabase/ssr opts a route into dynamic rendering, so there is no Full Route Cache entry to serve from. Nothing absorbs the refresh.

Multiply that by however many queries your dashboard runs, then by every open tab, and it is a strong candidate for your egress.

3. Timeouts: Realtime or pool exhaustion?

Neither hypothesis is well supported, but for different reasons.

Realtime is not a quota problem at your scale. Four channels across five users is nowhere near the Free plan's connection allowance. That said, being under quota does not rule out CHANNEL_ERROR or TIMED_OUT on channel join, which is the failure mode "connection lost" most naturally describes for someone running four postgres_changes subscriptions. Worth checking the Realtime logs specifically rather than dismissing it.

Pool exhaustion from setInterval is unlikely for a different reason: PostgREST does not open a Postgres connection per HTTP request. It holds a pooled connection and appears in pg_stat_activity as the authenticator role. Your polling adds HTTP requests, not connections. You can confirm what is actually connected:

select pid, usename as connected_role, application_name, state, query_start
from pg_stat_activity
order by backend_start;

authenticator is PostgREST, supabase_auth_admin is Auth.

Ranking your four patterns

By expected volume, worst first:

1. The N+1 loops. Every list render fans out into one query per row. Rewriting to select('*, profiles(*)') collapses N requests into one, and this is almost certainly your top entry in pg_stat_statements.
2. router.refresh() every 5 minutes, because it multiplies by queries-per-page.
3. The 60 second poll, which is 60 round trips per user-hour per open tab.
4. getSession() in middleware, which costs nothing on the network and should be changed for correctness rather than for load.

One cheap change worth making across all the timers: gate them on document.visibilityState === 'visible'. Background tabs left open overnight are pure waste, and given that your users are leaving tabs open by design, that alone may move the number more than any single refactor.

---

I have no access to your project's metrics, so which meter is at 100% is inference from your description rather than something I can see. The queries above are adapted from the docs and I have not run them against your project. I also did not verify your @supabase/ssr and auth-js versions: getClaims() needs a reasonably recent auth-js, so if the import isn't there, that's why.

[cekuu35]

Both answers above point at the number of requests — the timers, the N+1 loop, the middleware. That is the right place to start, but it assumes each request costs roughly the same. If the meter sitting at 100% turns out to be Compute or Disk IO rather than Egress, that assumption is where the explanation breaks, because with RLS enabled the cost per request is not constant. It scales with rows scanned.

An RLS policy is a predicate Postgres evaluates per row it examines. So the N+1 loop is the multiplier and the policy is the amplifier, and they compound: 20 tasks in a loop is 20 requests, and each of those 20 runs your profiles policy against every candidate row.

Four things make that per-row cost collapse. These are Supabase's own RLS performance recommendations, and the numbers are from the benchmark suite the docs cite — which, as it happens, is Gary's repo, so he can correct me if any of it has moved.

1. Wrap function calls in a select. This is the big one.

-- re-evaluated for every row
using ( auth.uid() = user_id )

-- evaluated once per statement, as an InitPlan
using ( (select auth.uid()) = user_id )

Benchmarked at 179 ms → 9 ms for plain auth.uid(). For a security definer helper function it is 178,000 ms → 12 ms. If any of your policies call an is_admin()-style helper unwrapped, that single edit is worth more than every timer in your post combined.

2. Index the columns your policies filter on. user_id in a policy with no index is a sequential scan on every request — 171 ms → under 0.1 ms in the same suite. Sequential scans are also exactly what shows up as Disk IO.

3. Add to authenticated. Without a TO clause the policy is evaluated for anon as well, instead of stopping at the role check.

4. Avoid joining the source table inside the policy. Invert it so the subquery filters on auth.uid() and the outer expression is a set membership — 9,000 ms → 20 ms.

You can check all of this without reading a single policy. In the dashboard: Advisors → Performance. Lint 0003_auth_rls_initplan flags exactly the unwrapped-function case, per policy, and 0006_multiple_permissive_policies flags tables where several permissive policies all run on every query. Both are free and take about ten seconds.

To confirm it is really RLS and not just query volume, extend the pg_stat_statements query above to include block reads:

select calls, mean_exec_time, total_exec_time, shared_blks_read, query
from pg_stat_statements
order by total_exec_time desc
limit 20;

Sort by calls and you find the N+1. Sort by total_exec_time and you find whether those calls are individually expensive. If a query with modest calls is near the top with high shared_blks_read, the policy is scanning far more than it returns.

And to see the policy in the plan, you have to ask as a role that is actually subject to it — as postgres you are the table owner and bypass RLS entirely, so the plan you get back is not the plan your app gets:

begin;
set local role authenticated;
set local request.jwt.claims = '{"sub":"<a real user uuid>"}';
explain (analyze, buffers) select * from tasks limit 20;
rollback;

If the policy appears as a Filter running over thousands of rows to return twenty, that is your answer, and it is independent of how often you call it.

None of this makes the timers or the N+1 loop fine — fix those regardless, and router.refresh() on an interval is genuinely the worst of the three. But if you fix only the request count and the meter stays high, this is where to look next.

[kaminagakur4]

I should say up front that I'm not certain this will fix it. I haven't been able to test the toggle on a project that has the beta, so treat the steps above as a way to narrow the problem down rather than a guaranteed fix. There's also one thing missing from your report that would help a lot, and that's the response bodies. You gave the status codes, 400 and then 500, but not what came back with them. Studio won't show you that either. The form surfaces error?.message in a toast and nothing more, so whatever the API actually returned never reaches the screen. The network tab is the only place you'll find it. A 400 on a config write normally names the field it turned down, and that alone would probably point straight at the cause. Without it we're all guessing, me included. A few other things might be involved, though I'd call these hunches rather than conclusions. The project is new, so it may have been created in a window where the OAuth server settings exist in the API but nothing sets up the record behind them. The 400 first and 500 after is also what you'd see if the first write was rejected cleanly and the retries then hit something half-written, which would explain why trying again made it worse instead of the same. And it's worth mentioning sa-east-1 and Auth v2.195.0 when you report it, since a gradual rollout by region or by Auth version would look just like a bug from where you're standing.