Connection Pool
A fixed set of reusable database connections shared by an application's requests, and one of the most common hidden capacity ceilings.
Opening a connection is expensive — a TCP handshake, TLS, authentication, and on some engines a process spawn — so applications hold a pool and lend connections out per query.
The pool is a concurrency limit, and it is frequently the real capacity ceiling rather than CPU or the database itself. When it saturates, requests queue for a connection; latency climbs with no error, and every application metric points at "the database is slow" while the database is idle. Pool utilisation is the single most valuable and least-collected saturation metric in most systems.
Size it with Little's Law — concurrency equals throughput times latency — not by guessing, and remember the total is per instance times instance count, which must stay under the server's connection limit. This is precisely why serverless functions need a connection proxy: hundreds of concurrent instances each wanting connections against a limit in the low hundreds.
Two related essentials: a separate pool per downstream dependency (a bulkhead), so one slow dependency cannot starve unrelated work; and a bounded acquisition timeout, so a request fails fast rather than waiting indefinitely for a connection that is not coming.