MongoDB Node.js driver pool sizing under Lambda concurrency
Parent: Lambda MongoDB Driver Pattern · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for MongoDB Node.js driver pool sizing under Lambda concurrency. 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
- Each MongoClient has a pool per server. maxPoolSize limits that pool, not all Lambda clients or all topology connections; pools grow on demand when no positive minimum is configured. (high confidence) [source]
- In the cached Node.js documentation, maxPoolSize defaults to 100 and each client opens up to two additional monitoring sockets per server. Its three-member replica-set example reaches 106 sockets for primary-only operations or 306 when all member pools grow. (low confidence) (verified as of 2026-10-31) [source]
- For conventional Lambda Event Functions, concurrent requests require separate execution environments. Combining that scaling model with per-client pools implies that increasing Lambda concurrency can multiply database clients even when each pool is small. (medium confidence) [source]
- Planning inference: with E connected environments, one client each and a three-node replica set, the documented socket ceilings imply E*(P+6) total sockets for primary-only operations or E*(3*P+6) when all three application pools fill, where P=maxPoolSize. These are topology-wide illustrations, not per-node limits or predicted occupancy; additional clients and retained idle environments require separate allowance. (medium confidence) [source]
- When a pool is exhausted, checkout waits. waitQueueTimeoutMS bounds that wait and defaults to unlimited waiting; the driver does not bound the number of waiting requests, so pool size alone does not bound backlog. (low confidence) (verified as of 2026-10-31) [source]
- Node.js driver 6.18.0 fixed background cleanup of idle connections when minPoolSize=0. Older-driver behavior can invalidate assumptions that idle connections will disappear during inactivity. (medium confidence) (verified as of 2026-10-31) [source]
How-to and procedures
- Create MongoClient outside the Lambda handler and reuse it across warm invocations. Each execution environment retains its own client; this does not create a fleet-wide shared pool. (high confidence) [source]
Problems, failure modes and limitations
- A pool of one can serialize parallel queries: MongoDB permits one operation per socket, and slow queries can delay faster ones. A universally optimal maxPoolSize of one, five, or one hundred is not established by these sources. (high confidence) [source]
Comparisons and alternatives
- A historical Mongoose issue reports scaling concerns after upgrading to driver 4.x/Mongoose 6 and observing a maximum pool default of 100. Current Mongoose documentation also lists 100; explicitly configure rather than assume older defaults persist. (high confidence) (verified as of 2026-10-31) [source]
- MongoDB processes one operation per socket at a time. A pool of one can therefore serialize parallel database operations within a handler or process; size for that local demand and slow-query interference rather than setting the pool equal to fleet-wide Lambda concurrency. (medium confidence) [source]
- Node.js maxConnecting limits parallel connection establishment within each pool. It controls local pool growth rather than providing one connection-creation limiter shared by all Lambda environments. (medium confidence) [source]
Facts and statements
- Sizing inference: budget each server separately by summing resident clients' possible application connections and monitoring sockets, leaving capacity for other clients. Across a topology, sum these per-server budgets. Invocation concurrency alone can undercount retained idle environments. (medium confidence) [source]
- For ordinary Lambda Event Functions, simultaneous invocations use separate environments. Choose per-environment pool capacity from parallel MongoDB operations inside the handler; setting it to fleet invocation concurrency repeats that capacity in every client. (medium confidence) [source]
- AWS Web Functions can handle multiple concurrent HTTP requests in one execution environment. Therefore, the Event Function rule of one invocation per environment must not be generalized to all Lambda modes; pool sizing must include within-environment request concurrency. (medium confidence) (verified as of 2026-10-31) [source]
- MongoDB's historical DRIVERS-1598 issue records serverless/Lambda users prematurely hitting Atlas connection limits. This establishes an engineering concern, not a measured universal pool-size threshold or proof of a current unresolved defect. (low confidence) [source]
- The reviewed Node.js and Mongoose docs list maxPoolSize=100 by default. This is a ceiling, not evidence that every newly created Lambda environment immediately opens 100 application sockets. (medium confidence) (verified as of 2026-10-31) [source]
- Atlas recommends maxIdleTimeMS=60000 for Lambda. Pair idle retirement with a workload-appropriate minimum; the Node.js documentation recommends minPoolSize=0 with idle cleanup for prolonged low activity. (medium confidence) (verified as of 2026-10-31) [source]
- An independent operational account published on 2026-08-31 describes reducing SQS worker pools from 25 to 5 while retaining 25 for its API. This historical, non-Lambda example supports workload-specific budgets; it does not establish 5 as an optimal Lambda pool size. (low confidence) [source]
Children
- Per-environment MongoClient reuse (frontier)
- Pool checkout queue limits (frontier)
- Monitoring socket connection budgets (frontier)
- Idle connection retirement under Lambda freeze and thaw (frontier)
Frontier under this node: Idle connection retirement under Lambda freeze and thaw, Monitoring socket connection budgets, Per-environment MongoClient reuse, Pool checkout queue limits