Lambda MongoDB Driver Pattern
Parent: Atlas Data API Removal · Published reference · snapshot 2026-10-22 · viability 3.80 / 5 (research)
↓ Facts as markdownall context files
Source-anchored research for Lambda MongoDB Driver Pattern. 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
- The reuse boundary is one Lambda execution environment. Because each MongoClient owns its own per-server pool, Lambda scale-out can create separate pools in separate environments; module-scope caching does not set a fleet-wide Atlas connection cap. This is an inference from AWS's environment reuse guidance and MongoDB's per-client pool model. (high confidence) [source]
- AWS Lambda Managed Instances can run multiple Node.js requests concurrently in one execution environment, sharing global objects. When using this mode, isolate mutable request state and use a database client pool that supports concurrent operations; the MongoDB Node.js driver documents one MongoClient supporting multiple concurrent requests. (medium confidence) (verified as of 2026-10-22) [source]
- MongoDB's current Node.js driver guide says releases earlier than 6.18.0 did not close idle connections when minPoolSize was 0 during inactivity. Verify the driver version before relying on minPoolSize=0 to reclaim idle sockets. (low confidence) (verified as of 2026-10-14) [source]
How-to and procedures
- Use context.callbackWaitsForEmptyEventLoop=false only with callback-style Node.js handlers; MongoDB's Lambda guide says the setting does not apply to async handlers. AWS currently documents callback-based handlers only for Node.js 22 and earlier runtimes. (high confidence) (verified as of 2026-10-22) [source]
Problems, failure modes and limitations
- AWS Lambda can purge idle connections, so a later invocation cannot assume an idle socket remains usable. MongoDB's Node.js driver exposes maxIdleTimeMS and minPoolSize to control idle pool behavior; tune these with the workload and test invocations after long idle periods. (medium confidence) (verified as of 2026-10-14) [source]
- Lambda can purge idle connections, so reuse does not guarantee an old socket remains usable. AWS warns that reusing a purged idle connection can error; Atlas recommends maxIdleTimeMS=60000 to reduce serverless timeout errors. (high confidence) (verified as of 2026-10-14) [source]
Facts and statements
- For standard AWS Lambda, create one Node.js MongoClient outside the handler and reuse it across warm invocations handled by the same execution environment. AWS documents execution-environment resource reuse, MongoDB's Atlas guide shows a module-scope client, and the Serverless Framework example implements the same pattern. Google's Atlas tutorial demonstrates the same instance-local pattern for Cloud Functions. (high confidence) [source]
- Each MongoClient maintains pools per server and opens monitoring sockets in addition to application connections. Set pool limits against expected Lambda concurrency and MongoDB topology; maxPoolSize is not a total connection cap for the deployment. (medium confidence) (verified as of 2026-10-14) [source]
- Each MongoClient maintains a pool for each server. The current Node.js driver docs list maxPoolSize=100 by default and up to two additional monitoring sockets per server per client, so estimate connection use across both topology and Lambda environments. (high confidence) (verified as of 2026-10-14) [source]
Children
- MongoDB Node.js driver pool sizing under Lambda concurrency (frontier, viability 3.98 / 5)
- Lambda Managed Instances and MongoClient concurrency safety
Frontier under this node: MongoDB Node.js driver pool sizing under Lambda concurrency (3.98)