PostgreSQL Connection Pooling: PgBouncer, Supavisor & Built-In

PostgreSQL Connection Pooling: PgBouncer, Supavisor & Built-In Every PostgreSQL connection creates a new OS process. Each one allocates roughly 5-10 MB of memory. A server with max_connections = 200 might use 2 GB just for connection overhead -- before a single query runs. At 500 connections, you're at 5 GB of memory consumed by connection infrastructure alone. If you've ever seen "too many connections" errors and responded by increasing max_connections , you've treated the symptom while creating a bigger problem. Why More Connections Make Things Worse Modern architectures multiply connections fast. 20 container replicas with 10 connections each = 200 persistent connections. During a rolling deployment, old and new replicas coexist briefly, doubling the count. Serverless functions are worse -- each invocation might open its own connection, creating hundreds of short-lived connections per second. Each new connection takes 50-100ms to establish (with TLS). PostgreSQL must fork a process,