PostgreSQL Config Tuner
Generate a postgresql.conf tuned for your hardware and workload, covering shared buffers, work memory, WAL sizing, autovacuum and the planner settings that assume spinning disks by default.
Last reviewed by the Radiatus Cloud team
Want this automated for your stack?
We build CI/CD, Kubernetes & IaC pipelines that scale.
The defaults are deliberately tiny
PostgreSQL ships with settings chosen so it starts on a machine with very little memory, which means the defaults are wrong for essentially every real server. shared_buffers defaults to 128 megabytes regardless of whether the machine has eight gigabytes or five hundred. random_page_cost defaults to 4.0, a ratio calibrated for spinning disks that makes the planner avoid index scans on SSD storage where the real ratio is close to 1.1. Neither is a bug; both need changing on any production instance.
work_mem is per operation, not per connection
The most dangerous setting is work_mem, because it applies to each sort, hash and merge node in a query plan, not to the session. A complex query with several sorts, running on a hundred connections, can allocate many multiples of the configured value simultaneously. Setting work_mem to a gigabyte on a machine with a hundred connections is how a server that looked fine for months runs out of memory during one unusual report.
Autovacuum is almost always too slow by default
The default autovacuum_vacuum_scale_factor of 0.2 means a table is only vacuumed after twenty percent of its rows have changed. On a hundred million row table that is twenty million dead tuples before anything happens, by which time the vacuum is enormous and the index bloat is permanent. Lowering the scale factor and raising the cost limit is the single most valuable tuning change on a busy write workload, and it is the one most often skipped.
Related tools
- CI/CD Security Gap Analyzer — Checklist based analyzer for CI/CD pipeline security gaps.
- Docker Security Scanner — A new tool extracted from the codebase.
- Terraform Scanner — A new tool extracted from the codebase.
- SQL Formatter — Format and indent SQL queries for readability. Handles joins, subqueries and CTEs, supports common dialects, and runs entirely in your browser.
Frequently Asked Questions
How much should shared_buffers be?
Around 25 percent of system memory as a starting point, capped near 16 GB on very large machines because the operating system page cache handles the rest more efficiently. Going much above 40 percent typically makes things worse by duplicating cached pages.
Why is work_mem dangerous?
It applies per sort or hash operation within a query, not per connection. A query with four sorts on a hundred connections can allocate four hundred times the configured value at once. Size it against max_connections and plan complexity, and raise it per session for known heavy queries instead.
What should random_page_cost be on SSD?
Around 1.1. The default of 4.0 assumes a random read costs four times a sequential one, which was true for spinning disks and is not true for SSD or NVMe. Leaving it at the default makes the planner avoid index scans it should be choosing.
How do I know if autovacuum is keeping up?
Query pg_stat_user_tables for n_dead_tup against n_live_tup and for last_autovacuum. A large dead tuple count with an old or absent last_autovacuum means it is falling behind, usually because the cost limit is throttling it rather than because it is not triggering.
Should I change these on a managed database?
Most managed services expose a subset through a parameter group and set the memory related ones from the instance class automatically. The autovacuum and planner settings are usually adjustable and are where most of the benefit is anyway.
Privacy & Security
Everything runs in your browser; nothing is uploaded.
How to Use
Enter your server resources and workload type to generate a tuned configuration.
Disclaimer: This tool is provided "as is" without warranty of any kind. Results are for educational and utility purposes.