findyourpilot/.agent/skills/supabase-postgres-best-practices/references/conn-pooling.md

title, impact, impactDescription, tags

title	impact	impactDescription	tags
Use Connection Pooling for All Applications	CRITICAL	Handle 10-100x more concurrent users	connection-pooling, pgbouncer, performance, scalability

Use Connection Pooling for All Applications

Postgres connections are expensive (1-3MB RAM each). Without pooling, applications exhaust connections under load.

Incorrect (new connection per request):

-- Each request creates a new connection
-- Application code: db.connect() per request
-- Result: 500 concurrent users = 500 connections = crashed database

-- Check current connections
select count(*) from pg_stat_activity;  -- 487 connections!

Correct (connection pooling):

-- Use a pooler like PgBouncer between app and database
-- Application connects to pooler, pooler reuses a small pool to Postgres

-- Configure pool_size based on: (CPU cores * 2) + spindle_count
-- Example for 4 cores: pool_size = 10

-- Result: 500 concurrent users share 10 actual connections
select count(*) from pg_stat_activity;  -- 10 connections

Pool modes:

• Transaction mode: connection returned after each transaction (best for most apps)
• Session mode: connection held for entire session (needed for prepared statements, temp tables)

Reference: Connection Pooling