PostgreSQL Connection Pooling at Scale

Postgres connections are expensive. A traffic spike that opens one connection per request can take down the database faster than application CPU saturates.

PgBouncer sizing

Start with max_client_conn at 10× expected app instances, default_pool_size tuned to CPU cores on the DB.

Prisma pool tuning

DATABASE_URL="postgresql://...?connection_limit=10&pool_timeout=20"

connection_limit per instance × replica count must stay below PgBouncer and Postgres max_connections. Leave headroom for migrations and admin consoles.

Detecting connection storms

Alert on:

• pg_stat_activity count > 80% of max_connections
• Rising pool_timeout errors in application logs
• Sudden spike in idle-in-transaction sessions

Traffic spike playbook

• Scale app horizontally with fixed per-pod pool limits—not unlimited pools
• Queue write-heavy batch jobs separately from interactive API pools
• Use read replicas for analytics queries

Connection pooling is not optional infrastructure—it is part of your availability model.