Why 1,000 DB Connections Hurt Performance: The Idle Connection Problem Explained

A distributed web crawler team discovered their Postgres database was hitting 95% CPU despite only 13 of roughly 1,000 open connections being active at any given time. The root cause was connection overhead: in Postgres, each connection runs as a real backend process consuming memory and CPU for coordination, even when idle. The team learned that AWS Aurora's max_connections limit is calculated from available memory, not from the database's actual capacity to handle concurrent work. This distinction between connection count and useful concurrency — the latter being CPU-bound — meant filling the connection pool was actively worsening performance rather than improving throughput. The insight reframed their scaling strategy: the metric worth optimizing is active concurrency, not the number of open connections.