Supabase Rate Limits

Overview

Supabase limits differ across PostgREST, Auth, Storage, Realtime, and Edge Functions. Use the current surface-specific documentation and project configuration rather than a universal requests-per-minute or requests-per-day table. Review pooling, bounded retries, pagination, and monitoring for the actual workload.

Prerequisites

• Active Supabase project (any tier)
• @supabase/supabase-js v2+ installed
• Project URL and anon/service-role key available
• Node.js 22+ for current SDK releases, or another supported SDK runtime

Instructions

Step 1 — Know your tier limits

Record the relevant endpoint, project configuration, plan, observation date, and current provider documentation. Auth, Storage, Realtime, Edge Functions, and database connections have different controls; a plan name alone does not establish one universal API request budget. See rate-limit-tiers.md for the per-surface review.

Step 2 — Pool connections with Supavisor

Supavisor is Supabase's built-in connection pooler (replaced PgBouncer). Pick the mode by workload:

Transaction mode (port 6543) returns a connection to the pool after each transaction — the right default for serverless. Session mode (port 5432) holds a dedicated connection for LISTEN/NOTIFY and prepared statements. Full client setup and connection-string formats are in implementation.md.

Step 3 — Retry, paginate, and batch

Wrap queries in an exponential-backoff retry that recognizes 429s and pool exhaustion:

// Retryable when the error is a rate limit, "too many requests",
// code 429, or PGRST000 (connection pool exhausted). Delay doubles
// per attempt with jitter, capped at maxDelayMs, honoring Retry-After.
const users = await withRetry(() =>
  supabase.from('users').select('id, email, created_at').eq('active', true)
)

Then cut request volume two ways: paginate large reads with .range(from, to) so responses stay small and avoid timeouts, and combine compatible writes using bounded batch upsert requests (choose chunk sizes for the actual payload and API behavior). The full withRetry, fetchPaginated, and batch/chunk helpers — plus dashboard monitoring steps — are in implementation.md.

Output

After applying this skill you will have:

• Dated, per-surface limit evidence and project-specific operating budgets
• Connection pooling configured via Supavisor (port 6543 transaction mode for serverless)
• Retry wrapper with exponential backoff handling 429 errors
• Paginated queries using .range(0, 99) to reduce payload size
• Batch upsert pattern reducing N requests to 1
• Dashboard monitoring configured for API usage alerts

Error Handling

Use response headers only where the endpoint documents them; honor Retry-After when supplied. Endpoint-specific error handling is in errors.md.

Examples

• Serverless Edge Function with a batch-inserting, rate-limit-safe client — see examples.md
• Connection-string selection per runtime (serverless vs long-running vs direct) — see examples.md
• Queue-based throttling and client-side header monitoring — see examples.md

Resources

• Supabase Platform Limits & Quotas
• Supavisor Connection Pooling
• Edge Functions Limits
• Storage Limits
• @supabase/supabase-js Reference

Next Steps

For securing your Supabase project with RLS policies and API key management, see supabase-security-basics. For optimizing database queries and indexing, see supabase-performance-tuning.