A relational database server enforces a maximum number of concurrent client connections. Explain what each connection actually costs the server, what happens when the cap is reached, and how you would reason about setting it.

## Where per-connection memory goes Every session gets its own memory, and it comes in two very different flavours. **Fixed overhead.** The backend's stack, its private catalog cache (metadata for the tables it touches), its plan and prepared-statement cache, and parser/executor scratch. This is on the order of a few megabytes per session and it exists even when the session is idle. A thousand idle sessions is not zero - it is gigabytes plus a thousand scheduler entries. **Query workspace.** Sort buffers, hash tables for joins and aggregation, and bitmap structures. Crucially this is allocated *per operation*, not per connection: one query with several sorts and hash joins can allocate the per-operation budget several times over. A configuration that looks safe at one active connection becomes an out-of-memory event at fifty. The worst-case arithmetic that matters in an interview: > peak memory ~ shared buffers + connections x (fixed per-session + concurrent memory-hungry operations x per-operation work memory) Most incidents where a database is killed by the OS out-of-memory reaper trace back to someone raising the connection cap or the work-memory setting without doing this multiplication. ## The cost that is not memory More sessions also mean more scheduler pressure, more cache-line contention on shared structures such as the buffer pool and lock manager, and, for process-per-connection engines, more page tables and context switches. Past the hardware's real concurrency limit, adding sessions makes total throughput *fall*, not plateau - the classic congestion curve. Two hundred active sessions on sixteen cores do not run faster than thirty; they run slower and with far worse latency variance. ## What happens at the cap The listener refuses new connections with an explicit "too many connections" style error. Established sessions are unaffected. Engines normally reserve a handful of slots for superuser or administrative logins precisely so an operator can still connect and see what is happening - a detail worth mentioning, because the alternative is a database you cannot diagnose. The dangerous dynamic is what happens next. Application instances see connection failures, treat them as transient, and retry immediately. Retries arrive faster than sessions are released, health checks start failing, orchestrators restart instances, and each restarted instance opens a fresh pool. That feedback loop turns a brief saturation into an outage, and it is why retry with backoff and jitter, plus a bounded pool, matter as much as the cap itself. ## Diagnosing connection pressure Look at the server's activity view and classify sessions rather than counting them: active, idle, and - the important one - **idle in transaction**. A pile of idle sessions is usually oversized pools; a pile of idle-in-transaction sessions is an application bug (a transaction opened and then left waiting on application logic or a remote call), and it is far more harmful because those sessions hold locks and block cleanup of old row versions. Also check whether connections are churning: high connect rate with short session lifetimes means something is not pooling at all. ## How to choose the number Do not start from the cap; start from useful concurrency. 1. Estimate real capacity - roughly the CPU cores available for query work plus some allowance for I/O-bound waits. This is tens, not thousands. 2. Size each application pool near that number divided across instances, and confirm it with latency under load rather than intuition. 3. Sum every consumer: application instances x pool maximum, plus background jobs, migrations, monitoring agents, replication and backup tools, BI clients, and human operators. 4. Add a margin for administrative sessions and a small burst allowance. 5. Set the cap a little above that sum - high enough that legitimate load is never refused, low enough that a runaway client hits a wall before memory does. The cap is a **guardrail, not a capacity plan**. If the answer to saturation is "raise the cap," the next event is an out-of-memory kill or a throughput collapse. The right answer is almost always to reduce demand for sessions - bound and share them - and to fix whatever holds them open. ## Interview framing The strong answer contains three moves: connections cost memory that multiplies per operation; useful concurrency is bounded by hardware so more sessions can reduce throughput; and the cap should be derived from the summed, bounded demand of every client rather than tuned upward in response to errors.