Creating a database connection is expensive—TCP handshake, authentication, protocol negotiation. Connection pooling reuses connections, dramatically improving performance.
The Problem
Without pooling:
Request 1 → Create connection → Query → Close connection
Request 2 → Create connection → Query → Close connection
Request 3 → Create connection → Query → Close connection
Each connection: ~50-100ms overhead
With pooling:
Request 1 → Get connection from pool → Query → Return to pool
Request 2 → Get connection from pool → Query → Return to pool
Request 3 → Get connection from pool → Query → Return to pool
Each connection: ~1ms overhead
Node.js with PostgreSQL
Loading code block...
Pool Size Calculation
Formula: connections = (core_count * 2) + effective_spindle_count
For SSDs (no spindles): connections ≈ core_count * 2
Example:
- 4 CPU cores
- SSD storage
- connections = 4 * 2 = 8
But also consider:
- Number of application instances
- Database server limits
- Query patterns
Loading code block...
Connection Lifecycle
Loading code block...
Transaction Handling
Loading code block...
Connection Pool Monitoring
Loading code block...
External Pool (PgBouncer)
Loading code block...
Pool modes:
- session: Connection per session (like no pooling)
- transaction: Connection per transaction (recommended)
- statement: Connection per statement (limited use)
Common Pitfalls
Loading code block...
Graceful Shutdown
Loading code block...
Conclusion
Connection pooling is essential for database performance at scale. Configure pool sizes based on your workload, monitor for exhaustion, and always release connections properly.
For high-traffic applications, consider an external pooler like PgBouncer between your app and database.