Max connections recommendation

Overview

DBtune monitors the total number of PostgreSQL connections your database uses (both active and idle) and notifies you if max_connections is set unnecessarily high. If your database is over-provisioned, DBtune recommends a tighter, safer value.

This recommendation is advisory: DBtune does not change max_connections for you. You apply the change yourself when you are ready.

warning

max_connections is a restart-required parameter. Applying a new value takes effect only after a PostgreSQL restart, so plan the change for a suitable maintenance window depending on your hosting.

Why it matters

PostgreSQL memory usage scales with the number of open connections. By reducing max_connections, you reduce the risk of running out of memory and causing the database to crash. This in turn lets you safely raise the memory available to each connection (for example work_mem), potentially improving performance.

Additionally, allowing too many connections at once risks the system getting overloaded. At its worst, the system can grind to a halt, often requiring a reboot or manual intervention to recover.

Where you see it

The recommendation appears on the Database dashboard, in the system information banner at the top of the page, the row showing your agent, PG version, vCPU, Memory and Max connections.

When a recommendation is available, an amber lightbulb icon appears next to the Max connections tile, with the tooltip "We have a recommendation". Clicking the lightbulb opens a modal titled Max connections recommendation.

If there is no recommendation, because your setting is already reasonable or there isn't enough data yet, no icon appears.

What the recommendation says

The modal explains the finding in plain language, using values read from your own database:

The window is a rolling 30 days: it always looks at the most recent 30 days and is recomputed daily, so it does not keep growing to 45 or 70 days over time.

How we generate recommendations

To ensure you only receive actionable and accurate advice, DBtune triggers a max_connections recommendation only when all of the following conditions are met:

1. An established baseline: Your database has been monitored for at least 7 days, so there is time to learn its usage pattern.
2. Adequate historical data: There is sufficient connection-usage data across the 30-day lookback period.
3. Known current state: Your current max_connections setting has been successfully read from the system.
4. Significant over-provisioning: Your current setting is meaningfully higher than your workload requires. Small differences are ignored to avoid alert fatigue.

Calculating the recommended value

DBtune scales its recommendation to fit your specific workload rather than using a static formula. We identify your peak connection usage from the past 30 days and apply a dynamic safety margin to provide comfortable headroom. Smaller workloads receive a more generous buffer, while larger workloads receive a tighter, optimized margin. The final result is capped, floored to a sensible minimum, and rounded to a clean number.

The table below gives a feel for how this plays out across different workloads:

Current limit	Peak usage over the last 30 days	Recommendation
100	40	No change — already right-sized
500	45	125
3000	750	1250

In the first row, the database is already close to a sensible minimum, so DBtune leaves it alone rather than nagging you. In the other two rows, the current limit sits well above what the workload needs, so DBtune proposes a tighter value with headroom to spare.

Important caveats

• 30-day window only: Weekly cycles are captured, but monthly batch jobs, quarter-end reporting or annual peaks may not be. Apply with caution if you know your workload has seasonal spikes. If you set max_connections below your real peak demand, PostgreSQL refuses new connections once the limit is reached — clients receive a FATAL: sorry, too many clients already error. The safety margin DBtune adds is designed to prevent this, but you should still account for known spikes the 30-day window may not have seen.
• Connection pooling signal: DBtune also tracks how much your connection counts fluctuate. Large swings can indicate you are not fronting the database with a connection pooler. This is surfaced as a signal to help you interpret the recommendation; in this version it does not change the recommended value itself.
• Refresh cadence: The recommendation is re-evaluated on a daily schedule, roughly every 24 hours.