Django REST Framework and PostgreSQL: Managing Connection Pool Exhaustion with CONN_MAX_AGE

Persistent Connection Behavior

In high-traffic Django REST Framework (DRF) deployments using PostgreSQL, the CONN_MAX_AGE setting determines whether database connections are closed at the end of a request or persisted for future use. While persistent connections reduce the overhead of repeated handshakes, they can lead to connection exhaustion if the number of concurrent worker processes exceeds the database server's max_connections limit.

Integration Constraints

Django does not natively manage a driver-level connection pool (such as psycopg2's internal pooling mechanisms) through standard settings. This creates a gap between the application's request-handling lifecycle and the database's available connection slots, especially when long-running API views hold connections open.

Given these constraints, how should the balance between CONN_MAX_AGE and external pooling tools like PgBouncer be configured to prevent intermittent exhaustion? Does the current architecture allow for a configurable pool size within the Django settings, or is external middleware the only viable solution for limiting total connections?