Linux and PostgreSQL in the Multiverse of Connections

PostgreSQL connections are expensive, their count is often the limiting factor for performance and stability. Connection pooling is a primary scaling tool for modern systems with microservices, short-lived clients, and bursty traffic. We all know it, but do we really understand why? This talk offers a deep dive into PostgreSQL and Linux architecture, explaining the concrete costs of “too many connections” in PostgreSQL’s process-per-connection model. We will discuss CPU overhead from context switching; kernel resources such as sockets and file descriptors; differences between the classic Completely Fair Scheduler (CFS) and its newer EEVDF-based scheduling approach; limitations of MVCC snapshot implementation across different PostgreSQL versions; accumulation of allocations in per-session memory contexts; and how much memory a query can allocate during execution. We will also look for guidance on “maximum active connections per CPU core” for OLTP vs. OLAP.

Key takeaways

• Pool when churn and burstiness dominate
• High connection counts amplify CPU context switching
• Idle sessions still consume memory
• Think in “active connections per core”
• Beware the thundering herd
• Version and platform choices influence limits