# Connection pooling and connection-storm control for Atlas (serverless and Lambda clients) > Source-anchored research for Connection pooling 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/) · 3 facets · 10 facts · page: https://llms-explorer.com/tree/connection-pooling-and-connection-storm-control-for-atlas-serverless-and-lambda-clients/ ## Problems, failure modes and limitations - maxPoolSize limits one connection pool, not the total connections from a Lambda fleet. MongoDB warns that separate clients create independent pools, and AWS provisions separate execution environments for concurrent requests, so per-client limits alone cannot cap fleet-wide Atlas connections. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/connection-string-options.md) - maxConnecting limits simultaneous connection establishment within one pool. MongoDB says raising it speeds pool growth but increases connection-storm risk, while a value that is too low can throttle pool fill and increase tail latency; it does not limit the number of Lambda environments. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/reference/connection-string-options.md) - MongoDB recommends checking sudden changes in connections.current, connections.active, connections.totalCreated, TLS handshake time, server logs, and Atlas Connections graphs when diagnosing a connection storm; request-driven scale-out can produce connection setup errors even when connection-limit exhaustion is not established. (medium confidence) — [source](https://www.mongodb.com/docs/manual/troubleshooting/connection-storms.md) - Atlas sets maximum incoming connections per node based on cluster tier and class; sharded-cluster limits apply per mongos router. When an application reaches the applicable limit, Atlas can reject connections, and a higher tier can raise the per-node ceiling. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/reference/atlas-limits.md) ## Comparisons and alternatives - As of 2026-10-22, Lambda Managed Instances with Node.js can process multiple concurrent requests in one execution environment and share global state across them. This differs from standard Lambda's one-in-flight-request-per-environment model, so standard Lambda's environment-to-pool arithmetic should not be applied unchanged. (high confidence) (verified as of 2026-10-22) — [source](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-nodejs-runtime.html) ## Facts and statements - For standard AWS Lambda functions, create one MongoClient outside the handler and reuse it across warm invocations in that execution environment. Creating a new MongoClient for every invocation creates independent pools and can exhaust database connection limits. (high confidence) — [source](https://www.mongodb.com/docs/atlas/manage-connections-aws-lambda.md) - For standard Lambda functions, reserved concurrency caps the maximum number of concurrent invocations and can bound the number of active execution environments and their client pools during a spike. Invocations are throttled at the configured ceiling, so this limits downstream connection pressure by trading away excess request concurrency. (high confidence) (verified as of 2026-10-22) — [source](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html) - In a July 2025 Stack Overflow question, the author reported that about ten Lambda functions were triggered per second and that each created a ten-connection pool. The author reported temporarily setting SQS batch size, Lambda reserved concurrency and maxConnectionPoolSize to one, and explicitly called this workaround neither scalable nor ideal. These are the author's reported settings, not validated MongoDB driver option names or general defaults. (low confidence) (verified as of 2025-07-19) — [source](https://api.stackexchange.com/2.3/questions/79707293?site=stackoverflow&filter=withbody) - In standard Lambda, scale-out adds execution environments as simultaneous requests exceed available environments. Each environment can hold its own MongoClient and independent pool, so client reuse within warm environments does not make total Atlas connection demand independent of Lambda scale. OneUptime's serverless example illustrates this multiplication but does not report a measured Atlas capacity result. (high confidence) — [source](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html) - Lambda can purge idle connections, so a cached client does not guarantee that every pooled socket remains usable across warm invocations. AWS recommends keep-alive behavior, and MongoDB's Lambda guidance says tuning maxIdleTimeMS can reduce serverless timeout errors. (medium confidence) — [source](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html)