PostgreSQL Tuning Calculator
Starting postgresql.conf values from memory, cores, connections, workload and storage: shared_buffers, effective_cache_size, work_mem, WAL and parallelism.
Free · No sign-up · Your inputs stay in your browser
Input
Starting settings for PostgreSQL
Output
postgresql.conf
415 characters
The same rules of thumb PGTune popularised: shared_buffers a quarter of memory, effective_cache_size three quarters (a planner hint, not an allocation), maintenance_work_mem a sixteenth up to 2 GB. work_mem is per sort or hash per query node, so one complex query can use several multiples of it; it is sized here so that every connection doing three at once still fits. Restart for shared_buffers; most others reload.
Runs in this browser. Nothing you paste is sent to a server.
About this tool
Method, assumptions, practical next steps, and limits.
The rules of thumb
PostgreSQL relies on the operating system's page cache as well as its own, which is why shared_buffers stays around a quarter of memory rather than most of it. effective_cache_size allocates nothing; it tells the planner how much data is likely cached, so it chooses index scans more readily. The resource consumption chapter of the manual documents each setting.
work_mem multiplies
work_mem applies per sort or hash operation, and a complex query can run several, in each of many connections. Set too high, a burst of reports exhausts memory; too low, sorts spill to disk, which EXPLAIN (ANALYZE, BUFFERS) shows as 'external merge'. Raise it per session for the queries that need it: SET work_mem = '256MB'.
SSDs
The default random_page_cost of 4 models spinning disks. On SSDs, 1.1 tells the planner random reads are nearly as cheap as sequential ones, and it uses indexes where it should.