Connection Pooling & Thread Pool Tuning (PgBouncer / HikariCP)

Relational databases were engineered in an era of monolithic, centralized application architectures.

In PostgreSQL, each incoming connection forks a dedicated OS backend worker process that consumes 5–10MB of private memory, initializes transaction buffers, and participates in internal lock management. Spawning 5,000 connections instantly consumes 25GB–50GB of RAM purely for connection bookkeeping metadata before a single query executes.

Furthermore, physical hardware limits concurrent instruction execution:

• A database server with 16 CPU cores can physically execute exactly 16 instructions in parallel at any single clock cycle.
• When 1,000 active client connections attempt to execute queries simultaneously, the OS kernel spends more CPU cycles performing thread context switches, TLB flushes, and spinlock arbitration than doing meaningful query processing.
• This condition—known as connection thrashing—causes query latency to degrade exponentially while aggregate throughput drops to near zero.