How can you optimize Postgres connection pooling for serverless Edge Functions?

Serverless functions scale by spinning up many short-lived instances, and each one that opens a direct Postgres connection can quickly exhaust Postgres's fairly low default connection limit (often in the low hundreds), since Postgres allocates real memory per connection rather than using lightweight threads.

Supabase addresses this with Supavisor, a connection pooler that sits in front of Postgres and multiplexes many client connections onto a much smaller pool of actual database connections. It offers two modes: transaction mode, which hands out a connection only for the duration of a single transaction and is well suited to the bursty, short-lived connections that serverless functions create, and session mode, which holds a connection for the client's full session and is closer to a direct connection — needed for features like prepared statements or session-level settings that transaction mode can't support.

In practice, the optimization is straightforward: point Edge Functions and other serverless callers at the transaction-mode pooler port rather than the direct database port, keep each function's own connection lifecycle short (open, query, close, don't hold connections across invocations), and reserve the direct connection or session-mode pooler for long-lived clients like a traditional backend server or local development.