How does Supabase handle connection pooling for high-concurrency workloads?

Supabase runs Supavisor, a Postgres-aware connection pooler, in front of every project's database. Instead of each application instance opening its own direct Postgres connection — which is expensive because Postgres spawns a full backend process per connection — clients connect to Supavisor, which maintains a smaller pool of real connections to Postgres and shares them across many incoming client connections.

Supavisor supports both transaction-mode pooling, where a connection is checked out only for the lifetime of a single transaction (ideal for serverless and Edge Functions with bursty, short-lived usage), and session-mode pooling, where a connection is held for a client's entire session (needed for features like prepared statements, LISTEN/NOTIFY, or advisory locks that assume a stable underlying connection). It also supports pooling across multiple Postgres instances via a single external endpoint, which matters for teams running read replicas or multi-tenant setups where connections need to be distributed rather than pointed at one fixed host.

The practical upshot is that connection scaling becomes a pooler configuration problem rather than something requiring a hand-rolled pooling layer (like PgBouncer manually configured) in application code, though teams with unusual connection patterns can still tune pool size and mode per use case.