# Connection pool tuning
Every driver keeps a pool per client. The knobs, in every driver:
- `maxPoolSize` (default 100): ceiling on connections per client.
- `minPoolSize` (default 0): warm connections kept ready.
- `maxIdleTimeMS`: how long an idle connection lives before being recycled.
- `waitQueueTimeoutMS`: how long an operation waits for a free connection before erroring.
## Sizing math
Total connections = clients x maxPoolSize. Count your clients: app instances, workers, serverless concurrency, plus mongosh sessions and tools. Size maxPoolSize from expected concurrent database operations per client, not from the default.
## Rules
- One client per process keeps the math simple. N clients with default pools is how you accidentally open 500 connections.
- If you see wait-queue timeouts under load, the pool is too small OR operations are too slow. Check slow queries first; raising maxPoolSize on top of slow queries just moves the bottleneck.
- `minPoolSize` above 0 avoids connect latency on burst traffic, at the cost of idle connections. Use it for latency-sensitive services.
- Lower `maxIdleTimeMS` (a few minutes) when clients sit behind load balancers or NATs that silently drop idle TCP connections.
## Verify
Watch Atlas Metrics, Connections, under real load. Steady near your computed ceiling is healthy; sawtooth or plateau-at-cap with errors means resize.