Connection Pooling

Connection pooling is a cache of database connections maintained so that the connections can be reused when future requests to the database are required. Opening a new database connection is computationally expensive and slow; pooling mitigates this overhead.

Establishing a TCP connection, performing the TLS handshake, and authenticating a database user requires multiple network round-trips. When a web server processes thousands of requests per second, creating a new connection for each request would overwhelm the database with handshake overhead and exhaust its memory.

A Connection Pool solves this by:

• Creating a fixed number of connections on startup (the "pool").
• When the application needs to query the database, it borrows a connection from the pool.
• Once the query finishes, the application returns the connection to the pool instead of closing it.
• If all connections are busy, new requests wait in a queue until one is returned.

Application vs. Proxy Pooling

Pool sizing is a critical tradeoff. A pool that is too small leaves application threads blocked waiting for a connection, increasing latency. A pool that is too large exhausts the database's memory and CPU, causing thrashing (where the DB spends more time context-switching between connections than executing queries). Surprisingly, a smaller pool (e.g., roughly 2x to 4x the number of CPU cores on the DB) often yields higher overall throughput than a massive pool.

• If an interview question involves Serverless architectures (like AWS Lambda) hitting a relational database, immediately bring up the connection exhaustion problem. Lambdas scale out massively and can overwhelm the DB; propose a proxy (like AWS RDS Proxy or PgBouncer).
• Mention that connection pools are usually configured with idle timeouts to reap dead connections and keep-alives to prevent firewalls from dropping silent TCP connections.