# Connection pool sizing and connection-storm control for Atlas (serverless and Lambda clients) > Source-anchored research for Connection pool sizing and connection-storm control for Atlas (serverless and Lambda clients). Run status: COMPLETED. Parent: [Cluster Tier Limits and Feature Gates as Cost Drivers (Connections, IOPS Caps, Minimum Tiers)](https://llms-explorer.com/tree/cluster-tier-limits-and-feature-gates-as-cost-drivers-connections-iops-caps-minimum-tiers/) · 4 facets · 18 facts · page: https://llms-explorer.com/tree/connection-pool-sizing-and-connection-storm-control-for-atlas-serverless-and-lambda-clients/ ## How it works - There is no universal minPoolSize for serverless workloads. A zero minimum can reduce idle sockets, while MongoDB's connection-storm guidance says a minimum far below the desired pool can cause rapid connection creation during heavy load or restarts and recommends considering prewarmed connections in those conditions. Choose between idle connection cost and burst ramp-up based on measured traffic. (medium confidence) — [source](https://www.mongodb.com/docs/manual/troubleshooting/connection-storms.md) - Self-reported serverless threads show that module-level reuse is not a fleet-wide connection cap. A 2025 MongoDB Community report describes maxPoolSize 5, minPoolSize 0, and a global cached Mongoose connection alongside 3–4.5K peak connections; a 2021 Serverless Forums report describes 250–450 connections despite caching. These reports do not establish root cause or a generally safe pool value. (low confidence) (verified as of 2025-09-29) — [source](https://www.mongodb.com/community/forums/t/aws-lambda-invocations-trigger-mongodb-connection-spikes/329196) - The current Node.js driver documentation lists maxPoolSize with a default of 100 for each server pool. A MongoClient can also open up to two monitoring connections per server, so its total socket count can exceed maxPoolSize; read preferences can cause additional server pools to grow. (high confidence) (verified as of 2026-10-22) — [source](https://www.mongodb.com/docs/drivers/node/current/connect/connection-options/connection-pools/) - The Node.js driver does not bound the number of requests waiting for a pool socket. waitQueueTimeoutMS defaults to 0, meaning no timeout; set a finite value when the application needs to bound checkout wait time during bursts. (high confidence) (verified as of 2026-10-22) — [source](https://www.mongodb.com/docs/drivers/node/current/connect/connection-options/connection-pools/) - minPoolSize is workload-dependent: MongoDB's Node.js guide describes minPoolSize 0 with maxIdleTimeMS as suitable for sustained low activity, while its connection-storm guide recommends raising minPoolSize toward maxPoolSize when measured demand or restarts create pool ramp-up spikes. In Lambda, account for per-environment multiplication before prewarming pools. (medium confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/drivers/node/current/connect/connection-options/connection-pools/) ## How-to and procedures - To diagnose connection pressure, inspect Atlas Metrics > Connections and serverStatus values such as connections.current, connections.active, and connections.totalCreated. Correlate these with Lambda concurrency and query latency to distinguish a high open-connection count, connection churn, and pool pressure. (high confidence) — [source](https://www.mongodb.com/docs/manual/troubleshooting/connection-storms.md) ## Problems, failure modes and limitations - Use layered storm controls: set a finite maxPoolSize to cap each endpoint pool, use maxConnecting to limit simultaneous connection establishment within each pool, and use Lambda reserved concurrency to cap the number of execution environments. maxConnecting and maxPoolSize are per-pool controls, not cluster-wide limits across a Lambda fleet. (high confidence) — [source](https://github.com/mongodb/specifications/blob/master/source/connection-monitoring-and-pooling/connection-monitoring-and-pooling.md) - MongoDB Atlas enforces a tier-specific maximum number of concurrent incoming connections per node. A client-side pool budget can still hit that server-side ceiling, so check the current Atlas limit for the deployment tier when sizing and alerting. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/troubleshooting/connection-storms.md) - Warm client reuse is best effort, not a guarantee that every idle socket remains usable. AWS says Lambda purges idle connections and warns that reuse can fail; its guidance recommends runtime keep-alive, while MongoDB drivers expose maxIdleTimeMS to remove idle pool sockets according to workload needs. (high confidence) (verified as of 2026-10-14) — [source](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) - maxConnecting limits how many new connections each pool establishes concurrently. The current default is 2; raising it speeds pool growth but increases connection-storm risk, while setting it too low can throttle checkouts and raise tail latency. (high confidence) (verified as of 2026-10-22) — [source](https://www.mongodb.com/docs/drivers/node/current/connect/connection-options/connection-pools/) - A OneUptime guide published March 31, 2026 suggests maxPoolSize values of 1–5 as a serverless starting heuristic. It is not a universal Atlas or Lambda default: the driver applies the limit per server, and Lambda scales separate environments for concurrent requests, so validate any small-pool setting against per-environment overlap and aggregate Atlas connections. (medium confidence) — [source](https://oneuptime.com/blog/post/2026-03-31-mongodb-configure-connection-pool-serverless/view) ## Facts and statements - MongoDB recommends creating the MongoClient outside the Lambda handler and reusing it across invocations. AWS independently recommends initializing database connections outside the handler so a warm execution environment can reuse them. Creating a client for every invocation creates additional pools and can raise Atlas connection counts. (high confidence) — [source](https://www.mongodb.com/docs/atlas/manage-connections-aws-lambda/) - Inference from AWS's Lambda lifecycle guidance: module-level client caching is local to one execution environment. Lambda provisions separate environments for concurrent requests and may reuse an environment for later requests, so the cached client does not create one shared pool across the function fleet. Fleet connection demand can therefore grow with concurrent environments. (high confidence) — [source](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html) - MongoDB driver pool caps apply per MongoClient and server endpoint, not across all endpoints or Lambda environments. The Ruby driver documentation says each client has a pool per server and may also open up to two monitoring connections per server, so max_pool_size alone can undercount that driver's total sockets; check the target language driver's own monitoring behavior. (high confidence) (verified as of 2026-10-22) — [source](https://github.com/mongodb/specifications/blob/master/source/connection-monitoring-and-pooling/connection-monitoring-and-pooling.md) - For Node.js clients connected to a many-shard Atlas cluster, MongoDB documents that the driver can connect to many mongos hosts by default and describes srvMaxHosts=3 as a way to cap connected hosts. This guidance is specific to the documented Node.js case and should be checked against the deployed driver version and topology. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/manage-connections-aws-lambda/) - Sizing inference: estimate the potential application connection count from the number of live Lambda execution environments multiplied by the per-environment pool capacity for each server the client uses, then add monitoring sockets per client and server. AWS can provision separate environments for in-flight requests, while MongoDB maintains pools per client and server, so maxPoolSize alone is not a deployment-wide connection cap. (medium confidence) — [source](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html) - AWS reserved concurrency can cap a Lambda function's concurrent execution environments and protect downstream capacity. Reaching that cap throttles invocations, so it controls traffic pressure but does not replace client reuse or pool sizing. (high confidence) — [source](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html) - Atlas cluster tiers enforce per-node connection ceilings. Compare observed counts with available capacity using Atlas connection metrics and serverStatus; if tuning pool size and environment fan-out does not resolve connection rejections near the ceiling, evaluate the deployment's tier capacity. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/manual/troubleshooting/connection-storms/)