Skip to main content

max_connections recommendation

The max_connections recommendation balances headroom for traffic spikes against the memory and operational cost of allowing too many sessions. This page describes the signals pocketPG uses, not the exact internal scoring formula.

Key inputs​

  • total_connections — current client backend count from pg_stat_activity
  • idle_connections / idle_in_txn — broken down by state
  • max_connections — current configured limit
  • work_mem, total_ram, shared_buffers — for memory pressure assessment
  • cache_hit_ratio, temp_gb_per_hour, I/O write pressure — secondary signals

Memory pressure​

pocketPG separates two concepts that are often mixed together:

  • Connection overhead — each allowed backend has a real process and memory cost.
  • Active query memory — work_mem is consumed by active sort/hash operations, not by every idle connection slot.
warning

work_mem is not reserved per connection slot. It is allocated per active sort/hash operation. pocketPG models active workload pressure separately from the configured connection ceiling.

Headroom and floor​

The recommendation keeps enough room for normal traffic bursts, but avoids recommending very high limits when the observed workload is mostly idle. Available memory, active session behavior, cache pressure, temporary file activity, and write pressure all contribute to the final guidance.

Pooler advisory​

When utilization is high but most sessions are idle, adding more connection slots usually makes the problem worse. In that case, pocketPG points you toward PgBouncer or application-side pooling instead of simply increasing max_connections.

Key design decisions​

  • Decreases are conservative — lowering max_connections may require a restart and can break traffic if the estimate is wrong.
  • Increases require pressure evidence — the recommendation should not raise the ceiling just because the current value looks low.
  • Poolers are preferred for idle-heavy workloads — many idle clients are usually an application architecture issue, not a PostgreSQL capacity issue.