Lambda Managed Instances and MongoClient concurrency safety
Parent: Lambda MongoDB Driver Pattern · Published reference · snapshot 2026-10-24 · skill mongodb-cohort-32c3803915b5
↓ Facts as markdownall context files
Source-anchored research for Lambda Managed Instances and MongoClient concurrency safety. 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.
Structure and components
- AWS's unsafe shared-client example uses a single pg.Client connection. The Node.js MongoClient instead contains per-server pools and explicitly supports concurrent requests. Inference: that example is not evidence that reusing a Node.js MongoClient is unsafe. (high confidence) [source]
How it works
- When a pool is full, operations wait for available connections; waitQueueTimeoutMS bounds that wait. A shared client's close() also closes sessions and transactions. Inference: avoid closing a reused client at the end of each overlapping invocation. (low confidence) [source]
How-to and procedures
- Avoid closing a shared MongoClient after each invocation: close() drains its sockets and closes sessions and transactions. Combining that documented lifecycle with overlapping handlers means per-invocation cleanup can affect other requests using the client. (medium confidence) [source]
Problems, failure modes and limitations
- Historical Lambda reports describe connection spikes despite attempted global reuse, while a driver issue records premature Atlas connection-limit exhaustion in serverless use. These reports establish an operational risk, not a reproducible Node.js MongoClient concurrency defect on Managed Instances. (medium confidence) [source]
- A 2024 Python Lambda performance-test thread distinguishes the server connection limit from a supposed MongoClient-instance limit. After the reporter clarified its cluster tier, the responder proposed a connection storm and suggested slower scale-out or reserved concurrency. This predates Managed Instances and is not its incident evidence. (low confidence) [source]
- LocalStack's December 1, 2025 announcement explicitly says its initial Managed Instances emulation did not implement multi-concurrency. Passing tests on that implementation cannot demonstrate that shared state is safe under overlapping invocations; this is a historical limitation, not a claim about today's LocalStack. (low confidence) (verified as of 2025-12-01) [source]
- MongoClient supports concurrent requests and maintains a pool per server. Combining MongoDB's reuse guidance with Lambda's per-worker initialization supports reusing a module-level MongoClient within each Node.js worker. AWS's warning about a single pg.Client connection does not establish that pooled MongoClient reuse is unsafe. (high confidence) [source]
- LocalStack's Lambda documentation currently says Managed Instances multi-concurrency is unavailable and parallel invocations use separate containers. Its launch blog states the same limitation. Passing these local tests therefore cannot establish safety under overlapping requests in a real Lambda worker. (high confidence) (verified as of 2026-10-23) [source]
Comparisons and alternatives
- Await operations in a transaction sequentially rather than using Promise.all on the same session. This restriction applies within the transaction; it does not prohibit independent concurrent operations through a shared MongoClient. (high confidence) [source]
- For capacity planning, count clients created by all workers and environments, then pools per server and monitoring connections. maxPoolSize limits an individual pool rather than aggregate deployment connections. Tune waitQueueTimeoutMS to bound socket checkout waits and maxConnecting to constrain parallel connection establishment. (high confidence) [source]
- The Intenics hands-on Python test observed an isolated global counter and inferred stateless execution. AWS documents separate Python worker processes, while Node.js handlers within a worker share globals. Treat that observation as runtime-specific evidence rather than a Node.js concurrency guarantee. (medium confidence) [source]
Facts and statements
- Node.js Lambda Managed Instances initializes each worker separately and can overlap asynchronous handlers within it. Keep invocation-specific mutable state local or use AsyncLocalStorage; a module-level client is scoped to its worker, not automatically shared across every vCPU. (high confidence) [source]
- For Node.js Managed Instances, reuse a module-scoped MongoClient within each worker and keep request-specific mutable state in handler-local variables or AsyncLocalStorage. This recommendation combines AWS's per-worker initialization model with MongoDB's client-reuse guidance; it does not mean passing one JavaScript client object between workers. (medium confidence) [source]
- Sharing MongoClient does not make ClientSession safe to share concurrently. The sessions specification requires sequential session use, and the Node.js transaction guide forbids parallel operations within one transaction. Give overlapping requests separate sessions and await transaction operations sequentially. (high confidence) [source]
- Pool capacity must account for every client, worker, execution environment, and contacted server; maxPoolSize is not a deployment-wide connection cap. Monitoring connections add overhead. Inference: choose pool limits together with invocation concurrency, then verify the total under load. (medium confidence) [source]
Children
- No children recorded.