# LangGraph Production Connection Pooling Inquiry **URL:** \ **Category:** LangGraph\ **Tags:** python-help\ **Created:** [October 2, 2025, 4:38pm UTC](https://forum.langchain.com/t/langgraph-production-connection-pooling-inquiry/1730 "2025-10-02T16:38:27Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Trapti](https://avatars.discourse-cdn.com/v4/letter/t/a4c791/32.png) [@Trapti](https://forum.langchain.com/u/Trapti)\ **Post date:** [October 2, 2025, 4:38pm UTC](https://forum.langchain.com/t/langgraph-production-connection-pooling-inquiry/1730/1 "2025-10-02T16:38:27Z")
Background We’re building a production multi-agent system using LangGraph with PostgreSQL checkpointing and have encountered a critical issue with connection pool management that we’d like to discuss with the LangGraph team. Our Architecture We have a multi-agent system with the following setup: ```python class BaseAgent(ABC): “”“Base class for all LangGraph agents”“” ``` \_shared_pool = None *# Class variable for shared pool* \_pool_context = None *# Store the context manager* ``` async def \__init_\_(_self_, _name_: str, _is\_supervisor_: bool = False): _# … initialization logic_ async def init\_async\_pool(_self_): “”“Initialize async connection pool and checkpointer”“” _if_ use\_checkpointing: self.checkpointer\_db = AsyncPostgresSaver(BaseAgent.\_shared\_pool) _await_ self.checkpointer\_db.setup() ``` \*\*Independent Agent Types with their own sub agents:\*\* - `SupervisorAgent` (analytics workflows) - `ThreeDPCustomAgent` (3D printing workflows) - `ProjectBodhiAgent` (project management workflows) - `TrialAnalysisAgent` (trial analysis workflows) - `FormulationAssistant` (formulation workflows) All agents inherit from `BaseAgent` and share the same `BaseAgent._shared_pool` for LangGraph checkpointing. ## The Problem: Pool Recreation Race Condition We’re experiencing a `psycopg_pool.PoolClosed: the pool ‘pool-1’ is already closed` error in production. Here’s what happens: ### Sequence of Events: 1. \*\*Database connection timeout\*\* occurs (infrastructure issue) 2. \*\*Health check detects\*\* the timeout in `_ensure_pool_health()` 3. \*\*Pool recreation\*\* is triggered via `_recreate_pool()` 4. \*\*Old pool is closed\*\* and new pool is created 5. \*\*Existing agent instances\*\* still reference the old, closed pool 6. \*\*Subsequent requests\*\* fail with `PoolClosed` error ### Code Flow: ```python _# Health check detects issue_ async def \_ensure\_pool\_health(_self_): _if_ not BaseAgent.\_shared\_pool or BaseAgent.\_shared\_pool.is\_closed(): _await_ self.\_recreate\_pool() _# ← Triggers recreation_ _# Pool recreation (PROBLEMATIC)_ async def \_recreate\_pool(_self_): _# Close existing pool_ _if_ BaseAgent.\_pool\_context: _await_ BaseAgent.\_pool\_context.\__aexit_\_(None, None, None) _# Reset pool references_ ``` BaseAgent.\_shared_pool = None BaseAgent.\_pool_context = None ``` _# Create new pool_ ``` BaseAgent.\_pool_context = AsyncConnectionPool(...) BaseAgent.\_shared_pool = *await* BaseAgent.\_pool_context.\__aenter_\_() ``` _# PROBLEM: Existing agent instances still have:_ _# self.checkpointer\_db = AsyncPostgresSaver(old\_closed\_pool)_ ``` ## Questions for LangGraph Team ### 1. \*\*Production Connection Pooling Best Practices\*\* - What are the recommended patterns for connection pooling in production LangGraph applications? - Should all independent supervisor agents (sub-agents used teh parent db connection) in a multi-agent system share the same connection pool, or should each agent have its own pool? - Are there any thread-safety considerations we should be aware of when sharing pools across multiple agent instances? ### 2. \*\*Pool Recreation Strategy\*\* - When a connection pool needs to be recreated due to infrastructure issues (timeouts, network problems, etc.), what’s the recommended approach? - How can we update existing `AsyncPostgresSaver` instances to use a new pool without breaking active agent instances? - Is there a built-in mechanism in LangGraph to handle pool recreation gracefully? ### 3. \*\*Agent Instance Management\*\* - How should we handle the scenario where one agent instance triggers pool recreation while other agent instances are actively serving requests? - Is there a way to atomically update all existing agent checkpointer references when the underlying pool changes? - Should we be tracking all active agent instances to update them when the pool changes? ### 4. \*\*Error Handling Patterns\*\* - What’s the recommended error handling strategy when database connectivity issues occur? - Should we implement retry logic, graceful degradation, or fail-fast approaches? - Are there any built-in LangGraph mechanisms for handling transient database issues? ## Current Workarounds We’re Considering ### Option 1: Graceful Degradation ```python async def restore\_session(_self_, _message_: Dict[str, Any]) → Dict[str, Any]: _try_: ``` state = *await* self.graph.aget_state(config) ``` _# … success logic_ _except_ PoolClosed: _# Return structured error response instead of retrying_ _return_ error\_response ``` ### Option 2: Agent Instance Tracking ```python class BaseAgent: ``` \_active_instances = set() *# Track all agent instances* ``` async def \_recreate\_pool(_self_): _# Recreate pool_ _# Update all tracked instances_ _for_ instance _in_ BaseAgent.\_active\_instances: ``` instance.checkpointer_db = AsyncPostgresSaver(BaseAgent.\_shared_pool) ``` ``` ### Option 3: Pool Reference Wrapper ```python class PoolReference: def \__init_\_(_self_): self.\_pool = None def get\_pool(_self_): _return_ self.\_pool def update\_pool(_self_, _new\_pool_): self.\_pool = new\_pool ``` ## Production Environment Details - \*\*Deployment\*\*: Docker containers in AWS - \*\*Database\*\*: PostgreSQL with connection pooling - \*\*Load\*\*: ~10 concurrent users expected - \*\*Agents\*\*: 5 different agent types, each handling different workflows - \*\*Checkpointing\*\*: Enabled for state persistence across sessions - \*\*Error Frequency\*\*: Occurs during database connectivity issues (timeouts, network problems) ## Request for Guidance We’d greatly appreciate guidance on: 1. \*\*Official best practices\*\* for production LangGraph connection pooling 2. \*\*Recommended patterns\*\* for handling pool recreation in multi-agent systems 3. \*\*Built-in mechanisms\*\* (if any) for graceful pool management 4. \*\*Error handling strategies\*\* for production environments 5. \*\*Any upcoming features\*\* or improvements related to connection pool management ---
**Author:** ![Trapti](https://avatars.discourse-cdn.com/v4/letter/t/a4c791/32.png) [@Trapti](https://forum.langchain.com/u/Trapti)\ **Post date:** [October 3, 2025, 2:36pm UTC](https://forum.langchain.com/t/langgraph-production-connection-pooling-inquiry/1730/2 "2025-10-03T14:36:02Z")
hello would appreciate if someone in langgraph product support can share persepctive? ---
**Author:** ![samirpatil2000](https://yyz1.discourse-cdn.com/flex007/user_avatar/forum.langchain.com/samirpatil2000/32/1444_2.png) [@samirpatil2000](https://forum.langchain.com/u/samirpatil2000)\ **Post date:** [October 30, 2025, 6:53am UTC](https://forum.langchain.com/t/langgraph-production-connection-pooling-inquiry/1730/3 "2025-10-30T06:53:13Z")
If we implement a ResilientAsyncPostgresSaver (same retry/reconnect semantics as proposed here [[NEW] Implement ResilientPostgresSaver for improved error handling and connection retries by samirpatil2000 · Pull Request #4008 · langchain-ai/langgraph · GitHub](https://github.com/langchain-ai/langgraph/pull/4008)) and have the saver acquire a fresh connection per operation from the existing async pool, it will address your issue. You won’t need to recreate the pool, so agents won’t hold stale references, and transient drops will be retried transparently. In short: resilient logic inside AsyncPostgresSaver + per‑call acquisition from the shared pool = no PoolClosed race.