work_mem
It is the riskiest setting to raise without modeling operations and concurrency. Do not equate max_connections with concurrent heavy queries.
PostgreSQL capacity planner
More than presets: model work_mem under load, WAL, I/O, parallelism, and the point where pooling becomes mandatory.
Use the container/VM memory limit.
work_mem is sized against active queries.
Compare with pg_settings and EXPLAIN.
Tuning catalog
The advisor covers every high-impact GUC group. Topology settings such as slots and senders must be confirmed against the real architecture before application.
It is the riskiest setting to raise without modeling operations and concurrency. Do not equate max_connections with concurrent heavy queries.
More WAL reduces checkpoint pressure, but needs disk capacity and RPO awareness. The plan adjusts its starting point by RAM and write intensity.
effective_cache_size does not reserve memory. It informs the planner about expected cache. random_page_cost and effective_io_concurrency must reflect real storage.
From calculation to real operations
Use this plan as a starting point. Then connect PostgreSQL to validate configuration against real load, concurrency, I/O, WAL, autovacuum, and query behavior — continuously, not only on tuning day.
Assisted diagnostic: we never request passwords or connection strings through forms, email, or WhatsApp.
What the SaaS tracks in PostgreSQL
No. work_mem is a limit per sort or hash operation, and one query can use multiple operations, parallel workers, and concurrent sessions at once.
No. It is a planner estimate of cache available in PostgreSQL and the operating system.
Many connections increase memory use and contention. For large client populations, PgBouncer is usually safer than raising max_connections.
No. PostgreSQL relies on operating-system page cache. On dedicated hosts, 25% is a common starting point and values above 40% are rarely the best initial choice.
Based on the official PostgreSQL resource-consumption documentation. Suggestions are starting points: validate with pg_settings, pg_stat_database, pg_stat_statements, EXPLAIN (ANALYZE, BUFFERS), and host metrics.