Skip to main content

Connections & Pooling

Connections are a finite resource in Postgres. Every connection consumes memory and system overhead. Managing them correctly is critical for Supabase and Postgres stability.

Why connections spike​

  • Traffic Spikes: More users means more app instances trying to connect.
  • Connection Leaks: App code that opens connections but fails to close them.
  • Long Transactions: Connections held open for long periods, preventing them from being reused.

Pooling Basics​

Connection poolers (like PgBouncer or Supavisor in Supabase) sit between your app and the database. They allow thousands of app connections to share a much smaller number of "real" database connections.

What to do​

  • Use the Pooler: Always use the pooled connection string (port 6543 on Supabase) for your application code.
  • Monitor Limits: pgpulse alerts you when you reach 85% of your max_connections.
  • Batch Jobs: For background workers, use a dedicated connection limit to prevent them from starving your API.
  • Fix Leaks: Identify "Idle in Transaction" connections in pgpulse—these are often signs of bugs in your application's transaction handling.