Connection Capacity
Parent: MongoDB Capacity Planning · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-1d798a0d85d1
↓ Facts as markdownall context files
Source-anchored research for Connection Capacity. 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
- Creating a new `MongoClient` for every request creates independent pools that multiply connections across concurrent requests or short-lived execution environments and can trigger connection storms. Reuse one client per application unless separate clusters require separate clients. (high confidence) [source]
Problems, failure modes and limitations
- Atlas caps concurrent incoming connections per node according to cluster tier and class; for sharded clusters, its documented connection limit applies per mongos router, so a per-node value is not a cluster-wide total. (high confidence) [source]
- Atlas connection-creation rate limits are separate from simultaneous-open connection limits. Current policy depends on tier and MongoDB version: M10 and M20 always have the rate limit, and M30+ has it on MongoDB 9.0 or later but not on earlier versions. (medium confidence) (verified as of 2026-10-23) [source]
- Self-managed and Atlas connection ceilings come from different layers. For self-managed `mongod`, `net.maxIncomingConnections` sets the incoming-connection limit unless a system-wide host limit binds first. Atlas limits vary by cluster tier and class and apply per node; for sharded clusters they apply per `mongos` router. There is no universal maximum-connection number across deployments. (high confidence) (verified as of 2026-10-14) [source]
- MongoDB defines `serverStatus.connections.current` as current clients connected to an instance and `connections.available` as unused connections available to new clients. Read these with workload, latency, and configured limits: high counts without corresponding workload can indicate driver or application misconfiguration, while Percona also lists connection leaks, batch jobs, and slow queries as causes of high connection counts. (high confidence) [source]
Comparisons and alternatives
- A connection ceiling is not a throughput guarantee: Atlas scales on memory and compute rather than connection count, while increased active connections can add load. Percona notes that high connection counts can reflect pool configuration, application design, resource use, or server configuration, so a count near the limit should be investigated alongside pool and server resource state. (high confidence) [source]
- MongoDB's self-managed storage FAQ states that each connection uses up to 1 MB of RAM and warns that too many open connections consume RAM that would otherwise be available to the working set. Because the source says 'up to', use the figure as upper-bound planning guidance rather than a deployment-specific measurement. (low confidence) (verified as of 2026-10-14) [source]
Facts and statements
- The current Atlas Core General-class table lists 1,500 concurrent connections per M10 node and 3,000 per M20 or M30 node. Limits vary by provider and class, Atlas reserves some connections for its services, and the page's M10 example leaves 2,980 across two secondary nodes after reserving 10 per node; verify the deployed configuration against the current table. (medium confidence) (verified as of 2026-10-23) [source]
- Atlas connection limits count simultaneous open incoming connections, not unique users or requests over a time window. Drivers retain idle sockets in pools for reuse, and those sockets remain open connections while idle. (high confidence) [source]
- MongoDB's `maxPoolSize` caps connections in a single driver pool; it is not a deployment-wide quota. Each `MongoClient` owns its pool or pools, topology-aware drivers create pools for individual servers, and monitoring sockets are additional to application-pool sockets. A connection estimate should sum client instances and destination-server pools, then include monitoring sockets and other clients. (high confidence) [source]
- In a sharded deployment, each `mongos` maintains connection pools to each shard, so router-side connection surges can add connection pressure on shard nodes. Atlas applies sharded-cluster connection limits per `mongos` router. (high confidence) (verified as of 2026-10-14) [source]
Children
- Driver-specific pool budget calculations (frontier)
- Atlas connection-rate limits (frontier)
Frontier under this node: Atlas connection-rate limits, Driver-specific pool budget calculations