Auth rate limits per IP when a server logs in many users (Sb-Forwarded-For?) and connection limits on the Free plan for a small load test

[chavesed]

Hello! We run a web app (Node server, React) backed by Supabase, where our server performs user logins on behalf of many end users, so all logins reach Supabase Auth from the same server IP.

1. Will the per-IP Auth rate limits (for example on /auth/v1/token) become a bottleneck in production with many users logging in through one server IP? Is the Sb-Forwarded-For header the recommended way for server-side callers to pass the real end-user IP, and how is it enabled for a project?

2. For a Free plan project, what are the limits for simultaneous database connections (direct and pooler) and API requests per second that we should respect when running a small load test with fictitious data on a demo project?

Thank you very much!

[Bri4real]

Hi!

There are two different limits to consider here: authentication rate limits and database connections.

For authentication, if all requests go through your Node.js backend, Supabase may see them as coming from the same IP. This can cause rate-limiting issues when multiple users try to log in.

Supabase supports the Sb-Forwarded-For header to pass the actual user's IP, but you'll need to enable IP Address Forwarding in your Auth settings and use a secret API key (sb_secret_...) on the backend. Just make sure you're getting the user's IP from a trusted proxy rather than blindly trusting the request headers.

For database connections, the Free plan (Nano) supports up to 60 direct PostgreSQL connections and 200 client connections through Supavisor. Using transaction pooling can help if you're handling multiple concurrent requests.

As for API requests per second, there isn't one universal limit across all Supabase services. Auth has its own rate limits, while database API performance depends on your queries and available resources.

You can find more details here:

• [Auth rate limits](https://supabase.com/docs/guides/auth/rate-limits)
• [Database connection pooling](https://supabase.com/docs/guides/database/connecting-to-postgres/pooling-and-limits)

One question though: are you handling authentication entirely through your Node.js backend, or does your React app also communicate directly with Supabase Auth? That makes a difference in how I'd approach this.

[jonjys]

1. Yes, all server-side logins share one per-IP bucket. Per the Auth rate-limit docs, /auth/v1/token (password, refresh-token, ID-token and PKCE grants) defaults to 150 requests per 5 minutes per IP, with bursts up to 30. Session refreshes your server makes count against the same bucket. Over the limit you get 429. You can raise it under Authentication → Rate Limits.

2. Sb-Forwarded-For is the documented fix, with three requirements:

• Set the header to the end user's IP.
• Send the request with a secret key (sb_secret_...). Publishable keys and the legacy anon/service_role keys are not supported.
• Enable it: Authentication → Rate Limits → IP Address Forwarding, or PATCH /v1/projects/{ref}/config/auth with {"security_sb_forwarded_for_enabled": true}.

const supabase = createClient(SUPABASE_URL, process.env.SUPABASE_SECRET_KEY!, {
  auth: { persistSession: false, autoRefreshToken: false },
  global: { headers: { 'sb-forwarded-for': clientIp } },
})

[0x496C6B696E]

Hey! Yes, the shared server IP can definitely become an issue once you have enough users logging in.

Supabase applies some Auth rate limits per IP, so if all your login requests come from the same Node server, they can end up sharing the same limit.

For /auth/v1/token, the default is currently 150 requests per 5 minutes per IP, with some burst allowance. So it's worth keeping an eye on that as your traffic grows.

Sb-Forwarded-For is actually meant for this kind of setup. You can enable IP Address Forwarding under Authentication > Rate Limits in your Supabase dashboard.

A couple of things to be aware of though:

• It requires a secret API key (sb_secret_...). The older anon and service_role keys won't work for IP forwarding.
• Only use it server-side, and make sure you're forwarding the actual client IP from a trusted proxy. Don't blindly trust an IP header sent by the browser.

For your second question, the Free plan runs on Nano compute, which currently has:

• 60 maximum PostgreSQL connections
• 200 pooler client connections

One important detail: those aren't 260 independent database connections. The pooler lets more clients share a smaller number of actual PostgreSQL connections.

If your Node server creates database connections directly, I'd strongly recommend using connection pooling rather than opening a new connection for every request.

As for API requests per second, Supabase advertises unlimited API requests on the Free plan, but that doesn't mean unlimited throughput. Your actual capacity will depend on query complexity, database load, CPU, and the endpoints you're hitting.

For a small load test, I'd start with low concurrency, gradually increase it, and watch the database connections, response times, and 429 errors in the dashboard.

I'd also test Auth and database queries separately. Otherwise, it can be difficult to tell whether you're hitting an Auth rate limit or simply running out of database resources.

These docs explain the limits pretty well:

• https://supabase.com/docs/guides/auth/rate-limits
• https://supabase.com/docs/guides/platform/compute-and-disk
• https://supabase.com/docs/guides/database/connecting-to-postgres/pooling-and-limits

Hope that helps!

[R3Dzf]

One implementation detail to add to the answers above: keep the Auth client and forwarded IP scoped to the current request. A module-level client whose headers or session are changed for each login can let concurrent requests interfere with one another. For a stateless login handler, disable persistent session storage and automatic refresh on that server client, and return/store each user's session separately. If you're using cookie-based SSR, use the request's cookie adapter instead.

For the load test, use several synthetic users and verify that each response belongs to the intended user, as well as monitoring 429s and latency. That catches shared-session bugs which a single test account won't reveal.

The official client setup and IP-forwarding examples are here:

• https://supabase.com/docs/guides/auth/server-side/creating-a-client
• https://supabase.com/docs/guides/auth/rate-limits

The secret key used for forwarding should remain on the server.