PostgreSQL Config Calculator
Generate a tuned postgresql.conf from your hardware and workload. Pick RAM, cores, connection count and workload type, and get shared_buffers, work_mem, WAL sizing and parallel query settings — calculated entirely in your browser.
What each setting does
- max_connections = 200 — Hard cap on backends; each one reserves memory even when idle.
- shared_buffers = 4GB — PostgreSQL's own page cache. Requires a restart to change.
- effective_cache_size = 12GB — Planner hint for OS + PostgreSQL cache. Allocates nothing.
- maintenance_work_mem = 1GB — Memory for VACUUM, CREATE INDEX and ALTER TABLE ADD FOREIGN KEY.
- checkpoint_completion_target = 0.9 — Spreads checkpoint writes over 90% of the interval.
- wal_buffers = 16MB — Shared buffer for WAL not yet written to disk.
- default_statistics_target = 100 — Sample size for ANALYZE; higher means better plans, slower ANALYZE.
- random_page_cost = 1.1 — Flash storage: random reads cost about the same as sequential ones.
- effective_io_concurrency = 200 — Concurrent I/O requests the planner assumes the storage can serve.
- work_mem = 10MB — Per sort/hash node, per parallel worker — not per query.
- huge_pages = off — Not worth configuring below ~32 GB of RAM.
- min_wal_size = 1GB — Floor for WAL recycling; avoids constant file creation.
- max_wal_size = 4GB — Triggers a checkpoint once this much WAL accumulates.
- max_worker_processes = 4 — Total background workers, including parallel query and extensions.
- max_parallel_workers_per_gather = 2 — Extra workers a single query may recruit for one Gather node.
- max_parallel_workers = 4 — Parallel workers available across the whole cluster.
- max_parallel_maintenance_workers = 2 — Workers for CREATE INDEX and parallel VACUUM.
Do more than postgresql config calculator — meet Chat2DB
Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.
How to use
- Enter your server's RAM and vCPU count, then choose the workload type that matches your database.
- Adjust max_connections — use a pooler such as PgBouncer instead of pushing this number above ~300.
- Copy the generated settings into postgresql.conf (or run the ALTER SYSTEM form) and restart PostgreSQL.
Frequently asked questions
How large should shared_buffers be in PostgreSQL?
About 25% of total RAM is the standard starting point for a dedicated database server, which is what this calculator uses. The operating system cache holds the rest, and effective_cache_size tells the planner how much total cache it can assume. On a shared machine or a desktop, a much smaller value such as 1/16 of RAM is safer.
Why is work_mem so much smaller than my available memory?
work_mem is allocated per sort or hash node, per parallel worker — not per query or per connection. A single complex query can therefore use several multiples of work_mem at once, and every connection can do this concurrently. The calculator divides available memory by the connection count and the parallel worker count so that a burst of concurrent queries cannot exhaust RAM.
Do I need to restart PostgreSQL after changing these settings?
shared_buffers, max_connections and huge_pages require a full restart. Most other values here, including work_mem, maintenance_work_mem, random_page_cost and the WAL sizes, can be applied with a configuration reload via SELECT pg_reload_conf() or pg_ctl reload. Use the ALTER SYSTEM output format if you prefer to change settings over a SQL connection.
