Django CONN_MAX_AGE vs PgBouncer for NetBox connection pooling under PostgreSQL max_connections constraint

Goal

Prevent intermittent database connection pool exhaustion in a NetBox deployment serving variable API traffic, webhook bursts, and scheduled housekeeping jobs.

Constraint

PostgreSQL max_connections is fixed (e.g., 100–200). Each Gunicorn worker, RQ worker, and runhousekeeping invocation holds a dedicated connection when DATABASE_CONN_MAX_AGE > 0. Under peak load the sum of web workers + background workers can exceed the limit, causing transient FATAL: remaining connection slots reserved errors.

Uncertainty

NetBox documentation recommends CONN_MAX_AGE for simplicity and references PgBouncer transaction pooling as an alternative, but does not define a workload threshold (requests/sec, worker count, background job frequency) at which the external pooler becomes necessary. Sizing guidance also omits background processes.

Questions

1. At what combined web-worker + background-worker count does CONN_MAX_AGE alone reliably exceed a typical PostgreSQL max_connections setting?
2. Does enabling PgBouncer transaction pooling introduce any NetBox ORM incompatibilities (prepared statements, temporary tables, SET LOCAL) that would require code changes?
3. What monitoring queries or NetBox health-check extensions can surface pool saturation before it causes request failures?