Docs Home → Develop Applications → MongoDB Manual
Connection Pool Overview![](/docs/v5.3/assets/link.svg)
On this page
This document describes how to use a connection pool to manage connections between applications and MongoDB instances.
What is a Connection Pool?![](/docs/v5.3/assets/link.svg)
Definition![](/docs/v5.3/assets/link.svg)
A connection pool is a cache of open, ready-to-use database connections maintained by the driver. Your application can seamlessly get connections from the pool, perform operations, and return connections back to the pool. Connection pools are thread-safe.
Benefits of a Connection Pool![](/docs/v5.3/assets/link.svg)
A connection pool helps reduce application latency and the number of times new connections are created.
A connection pool creates connections at startup. Applications do not need to manually return connections to the pool. Instead, connections return to the pool automatically.
Some connections are active and some are inactive but available. If your application requests a connection and there’s an available connection in the pool, a new connection does not need to be created.
Create and Use a Connection Pool![](/docs/v5.3/assets/link.svg)
Use an Instance of your Driver's MongoClient
Object![](/docs/v5.3/assets/link.svg)
Most drivers provide an object of type MongoClient
.
Use one MongoClient
instance per application unless the
application is connecting to many separate clusters. Each
MongoClient
instance manages its own connection pool to the
MongoDB cluster or node specified when the MongoClient
is created.
MongoClient
objects are thread-safe in most drivers.
Note
Store your MongoClient
instance in a place that is globally
accessible by your application.
Authentication![](/docs/v5.3/assets/link.svg)
To use a connection pool with LDAP, see LDAP Connection Pool Behavior.
Sharded Cluster Connection Pooling![](/docs/v5.3/assets/link.svg)
mongos
routers have connection pools for each node in the
cluster. The availability of connections to individual nodes within a
sharded cluster affects latency. Operations must wait for a connection
to be established.
Connection Pool Configuration Settings![](/docs/v5.3/assets/link.svg)
To configure the connection pool, set the options:
through the MongoDB URI,
programmatically when building the
MongoClient
instance, orin your application framework's configuration files.
Settings![](/docs/v5.3/assets/link.svg)
Setting | Description |
---|---|
Maximum number of connections opened in the pool. When the
connection pool reaches the maximum number of connections, new
connections wait up until to the value of
Default: | |
Minimum number of connections opened in the pool.
The value of Default: | |
Most drivers default to never time out. Some versions of the
Java drivers (for example, version 3.7) default to Default: | |
Number of milliseconds to wait before timeout on a TCP connection. Do not use Setting low socket timeouts may result in operations that error before the server responds. Default: | |
Amount of time that a connection can be idle in the pool before
closing. Idle connections close until the number of
open connections equals Default: See your driver documentation. | |
Maximum wait time in milliseconds that a can thread wait for
a connection to become available. A value of Default: | |
Minimum number of outbound connections each TaskExecutor
connection pool can open to any given Default: This setting only applies to sharded deployments. | |
Maximum number of outbound connections each TaskExecutor
connection pool can open to any given Default: 2 64 - 1. See
This setting only applies to sharded deployments. |