A builtin rate limiter algorithm

Is your feature request related to a problem? Please describe.

Rate limiting is one of the most common production requirements when building on Supabase. Today, developers must implement their own solutions whether through custom Postgres functions, Redis in Edge Functions, external proxies (Cloudflare, Zuplo, etc.), or third-party services. This adds boilerplate, maintenance overhead, and inconsistency across projects.

Describe the solution you'd like

A native, built-in rate limiter that is:

• Configurable directly from the Supabase Dashboard (or via config.toml for self-hosted)
• Supports common strategies: per-IP, per-user (via Auth), per-API-key, per-endpoint/table
• Works across PostgREST, Storage, Edge Functions, and Realtime
• Supports flexible windows (per-minute, per-hour, sliding, token-bucket, etc.)
• Returns clear 429 responses with Retry-After headers

Additional context

We recently implemented a production-grade rate limiter for our own backend and have been using it successfully. We would love to contribute this implementation back to Supabase so it becomes a first-class, built-in feature.

We are happy to open a PR and adapt the code to fit Supabase’s architecture as well as documentation and tests.

Questions for the team

• Do you already have plans (or an internal roadmap item) for native rate limiting?
• Which component would be the best place to integrate this? (PostgREST, a new Postgres extension, Edge Functions helper, Kong layer, etc.)

We’re ready to move forward with a PR once we have guidance. Thank you!