Why do applications keep a pool of open database connections instead of opening a new connection for each request, and what does a pool actually do when code asks for one?

## The cost being avoided A database connection is not a socket you can cheaply re-open. Establishing one means: a TCP handshake; optionally a TLS handshake with certificate verification, adding round trips; an authentication exchange; then server-side session setup, where the engine allocates an execution context - a process or thread - gives it private memory, and loads role and database metadata. On a LAN this is typically single-digit milliseconds; across availability zones with TLS it is worse. Compared with a 1 ms indexed lookup, paying that per request means most of the latency budget goes to setup. The server side is the harder constraint. Each session holds memory whether or not it is doing anything, and the engine enforces a maximum connection count. Open-per-request under load means constant churn against that ceiling and, when a spike arrives, outright connection failures. ## What the pool provides A pool is a bounded cache of live, authenticated sessions plus a queue. **Acquire.** A caller asks for a connection. If an idle one exists, it is validated cheaply and handed over. If not, and the pool is below its maximum, a new connection is created. If the pool is at its maximum, the caller waits on the queue until one is returned or the acquisition timeout expires - at which point the caller gets a clear "could not obtain connection" failure rather than piling more load on the database. **Release.** The caller returns the connection. A well-behaved pool rolls back any open transaction and resets session state so the next borrower does not inherit temp tables, changed settings, or an assumed role. The connection stays open. **Maintenance.** Pools validate connections before handing them out (a lightweight ping, or a check that the socket is alive), enforce a maximum lifetime so connections are recycled - which is what lets a database failover or an IP change actually take effect - cap idle time to release surplus capacity, and detect connections a caller borrowed and never returned (leak detection). ## The limit is a feature Beginners see a pool as a latency optimisation. The more important property in production is that `maximumPoolSize` is a **hard concurrency limit** on how much work the application can push at the database. Since a database's useful concurrency is bounded by cores and storage, a bounded pool converts an overload into an orderly queue on the application side, where you can time out and shed load, rather than a thundering herd of sessions that makes every query slower. Every application instance's pool maximum, summed across the fleet, must stay comfortably under the server's connection cap. ## What pooling does not fix - It does not add database capacity. If queries are slow, a pool just queues faster. - It does not make session state safe by itself: without a reset on release, reuse leaks settings, temp objects, and prepared statements between unrelated requests. - It does not excuse holding a connection across slow work. Fetching a connection at the start of a request and holding it through remote API calls or user interaction pins pool slots and destroys throughput; borrow late, release early. - It does not survive misconfiguration: a pool maximum larger than the database can serve just moves the failure downstream. ## When you might skip it Short-lived batch jobs with a single serial connection, or an embedded/local database with negligible connect cost, may not need one. Serverless functions are the interesting exception: each instance's pool is tiny but instances are numerous, so pooling often has to move to a shared external proxy in front of the database instead of living in the process. ## Interview framing Name both halves: amortising expensive setup, and bounding concurrency against a server that has a finite connection budget. Then mention the reset-on-release and maximum-lifetime behaviours, which show you have operated a pool rather than only configured one.