| name | supabase-rate-limits |
| description | Manage Supabase rate limits and quotas across all plan tiers.
Use when hitting 429 errors, configuring connection pooling, optimizing
API throughput, or understanding tier-specific quotas for Auth, Storage,
Realtime, and Edge Functions.
Trigger with "supabase rate limit", "supabase 429", "supabase throttle",
"supabase quota", "supabase connection pool", "supabase too many requests".
|
| allowed-tools | Read, Write, Edit, Bash(supabase:*), Bash(node:*), Bash(npx:*), Grep |
| version | 1.53.0 |
| license | MIT |
| author | Jeremy Longshore <jeremy@intentsolutions.io> |
| tags | ["saas","supabase","rate-limiting","reliability","quotas"] |
| compatibility | Designed for Claude Code, also compatible with Codex and OpenClaw |
Supabase Rate Limits
Overview
Supabase enforces rate limits and quotas across every API surface — PostgREST, Auth, Storage, Realtime, and Edge Functions — and the numbers scale by plan tier. This skill gives you the exact per-tier limits, connection pooling via Supavisor, retry/backoff and pagination patterns, and dashboard monitoring so you stay within quota and handle 429 errors gracefully.
Prerequisites
- Active Supabase project (any tier)
@supabase/supabase-js v2+ installed- Project URL and anon/service-role key available
- Node.js 18+ or equivalent runtime
Instructions
Step 1 — Know your tier limits
Rate limits differ per surface and per plan. The headline API limits:
| Metric | Free | Pro | Enterprise |
|---|
| Requests per minute (RPM) | 500 | 5,000 | Unlimited (custom) |
| Requests per day (RPD) | 50,000 | 1,000,000 | Unlimited (custom) |
Auth, Storage, Realtime, Edge Functions, and Database connections each carry their own quotas. See the full per-surface breakdown in rate-limit-tiers.md before you architect.
Step 2 — Pool connections with Supavisor
Supavisor is Supabase's built-in connection pooler (replaced PgBouncer). Pick the mode by workload:
| Use case | Mode | Port |
|---|
| Serverless / Edge Functions | Transaction | 6543 |
| Next.js API routes | Transaction | 6543 |
| Long-running workers | Session | 5432 |
| Realtime subscriptions | Direct (no pooler) | 5432 |
| Prisma / Drizzle ORM | Transaction + ?pgbouncer=true | 6543 |
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:
