Scalingo Managed PostgreSQL and Application-Level Connection Pooling Interoperability

Managing database connectivity in a containerized environment requires balancing application-level pool sizes against the global limits of the managed database instance. In a Scalingo deployment, each container maintains its own independent connection pool, meaning the total number of concurrent sessions is the product of the pool size per container and the number of active containers.

As the application scales horizontally, the aggregate demand for connections can quickly exceed the max_connections limit of the PostgreSQL instance, leading to connection exhaustion. While external poolers like PgBouncer are available to mitigate this, there is a design trade-off between relying on application-side pooling for low latency and using a proxy for higher concurrency.

• What is the recommended strategy for calculating the optimal per-container pool size to prevent saturation during peak horizontal scaling?
• Under what specific load conditions does the overhead of an external pooler outweigh the benefits of application-level connection management?