Connection Pool Tuning
Parent: MongoDB Connection String URI · Published reference · snapshot 2026-10-22 · skill mongodb-cohort-2a03c480ee30
↓ Facts as markdownall context files
Source-anchored research for Connection Pool Tuning. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- Tune maxPoolSize against observed checkout contention and server headroom. Raising it can relieve waits when requests exhaust a pool, but high database CPU or excess connection attempts call for lowering the cap or reducing application concurrency. Oversized pools also consume client memory, so benchmark representative workloads and monitor before and after changes. (high confidence) [source]
- A nonzero minPoolSize keeps a floor of connections in each server pool and can reduce connection-creation delay at startup or during bursts, but it also retains idle sockets. Use it when measured warm-up cost justifies the idle resource use; zero minimum with an idle timeout lets suitable low-activity workloads shed unused connections. (high confidence) [source]
- maxConnecting is separate from maxPoolSize: it limits how many connections one pool may establish concurrently, while maxPoolSize limits the pool's total application connections. Raising maxConnecting allows a pool to replenish sockets faster; use it when measured connection setup time is the bottleneck. (high confidence) [source]
- For MongoDB drivers that implement a connection pool, maxPoolSize caps all connections in that pool, including checked-out and available connections. When the cap is reached, new operations wait for a connection; waitQueueTimeoutMS can bound that wait. (high confidence) [source]
- Choose maxPoolSize from observed concurrency and latency needs, then benchmark with production-like load. MongoDB's tuning guide recommends increasing it when workload and active connections are unexpectedly low, and reducing it or application threads when database CPU or connection attempts are higher than expected. AWS also cautions that an oversized pool can create unused connections, consume application memory, and hurt performance. (high confidence) [source]
- Track actual connection use and acquisition behavior when tuning. IBM documents db.serverStatus().connections counters such as current, available, rejected, and totalCreated, while MongoDB documents waitQueueTimeoutMS as a bound on waiting for pool checkout. (medium confidence) [source]
How-to and procedures
- Use minPoolSize when a measured startup or warm-connection need justifies keeping connections ready. Because the minimum applies to each pool, include every MongoClient and topology server when estimating the idle connection floor; on-demand pools avoid keeping that baseline when cold connection setup does not affect the workload. (medium confidence) [source]
Problems, failure modes and limitations
- A MongoClient maintains pools for the servers in its deployment topology, so the configured pool limit is not a deployment-wide connection total. MongoDB's tuning example multiplies maxPoolSize by replica-set members for one application's outgoing sockets and by application servers for incoming sockets at each mongod; each additional MongoClient contributes its own pools. (high confidence) [source]
- A connection checkout wait or wait-queue timeout is a symptom to diagnose before increasing maxPoolSize. Slow queries can hold connections and cause requests to wait; inspect query duration and pool use alongside database CPU and connection counts before changing the cap. (medium confidence) [source]
Comparisons and alternatives
- In the Node.js driver, waitQueueTimeoutMS bounds how long a request can wait for a socket when the pool is full; when it expires, the request fails with a connection error. This setting bounds queue latency rather than increasing pool capacity, so choose it against the request's latency budget. (high confidence) [source]
Facts and statements
- Each MongoClient maintains a pool for each server in its topology. maxPoolSize caps each application pool, while monitoring sockets add to total open connections; estimate the total across client instances and topology members before setting the cap. (high confidence) [source]
- Current MongoDB driver guides list different maxPoolSize defaults: 100 for Node.js and 10 for Rust. Defaults are driver-specific, so check the target driver's exact release before relying on a default or copying a setting. (high confidence) (verified as of 2026-10-22) [source]
Children
- No children recorded.