Connection Pooler -- Running out of connections

Customer Need:

The customer recently reintroduced a connection pooler, which improved performance but introduced a new issue: under burst load (every ~10 minutes), some systems are unable to connect due to pooled connection limits. Most services can queue, but critical systems—such as administrative and monitoring tools—require uninterrupted, immediate access to the database.

Feature Request:

Allow users to reserve a subset of database connections (e.g., 100 out of 500 max connections) exclusively for direct connections, while letting the remaining (e.g., 400) be managed by the connection pooler.

Current Limitation:

This configuration is not currently possible. The pooler (e.g., PgBouncer) will utilize all available connections up to max_connections, and there is no way to enforce or reserve a subset for direct connections.

Suggested Workaround (from Platform Team):

  • Use a single entry point for all connections—either all through PgBouncer or all direct.
  • Set max_connections to 500.
  • Rely on PgBouncer’s internal queueing and performance management to handle critical connections.
  • Note: The system reserves 17 connections for superuser access, so this may help ensure admin access remains available during spikes.

Customer Value:

This feature would allow critical systems to maintain consistent DB access, improving reliability and uptime during bursty load scenarios.