PostgreSQL Config Generator
Generate optimized postgresql.conf settings based on your server hardware and workload. Free PGTune alternative.
# PostgreSQL Configuration # Generated for: 16GB RAM, 4 CPUs, SSD, Web Application # PostgreSQL 16 # Generated by DevToolKit — https://www.devtoolkit.site/postgres-config/ # Memory shared_buffers = 4GB # 25% of RAM — primary PostgreSQL cache effective_cache_size = 12GB # Estimate of OS + PG cache available for queries work_mem = 20MB # Per-operation memory for sorts and hash joins maintenance_work_mem = 1GB # Memory for VACUUM, CREATE INDEX, ALTER TABLE # Connections max_connections = 200 # Typical for Web Application workloads # WAL wal_buffers = 64MB # ~3% of shared_buffers, capped at 64MB min_wal_size = 1GB # Minimum WAL retained on disk max_wal_size = 4GB # Triggers checkpoint when exceeded checkpoint_completion_target = 0.9 # Spread checkpoint writes over 90% of interval # Disk random_page_cost = 1.1 # Low value tells planner random I/O is cheap (SSD) effective_io_concurrency = 200 # SSD can handle many concurrent I/O requests # Parallelism max_worker_processes = 8 # Background worker pool size max_parallel_workers_per_gather = 2 # Workers per parallel query node max_parallel_workers = 8 # Total parallel workers across all queries max_parallel_maintenance_workers = 2 # Workers for parallel CREATE INDEX, VACUUM # Logging log_min_duration_statement = 1000 # Log queries slower than 1000ms
Free PGTune Alternative — PostgreSQL Configuration Generator
This tool generates optimized postgresql.conf settings based on your server's RAM, CPU cores, storage type, and workload profile. It follows the same tuning algorithms as PGTune, adapted from official PostgreSQL documentation and community best practices. Unlike PGTune, it runs entirely in your browser — your server specs are never sent to any external server.
How shared_buffers Is Calculated
shared_buffers is PostgreSQL's primary memory cache for table and index data. The recommended starting point is 25% of total system RAM. For a server with 16 GB RAM, that's 4 GB. For desktop and development use, 128 MB to 512 MB is usually sufficient. On systems with more than 64 GB RAM, you can allocate up to 40% for shared_buffers, though going beyond 8–16 GB often shows diminishing returns as the OS page cache becomes more efficient.
Understanding work_mem
work_mem controls how much memory each sort operation, hash join, or hash-based aggregation can use before spilling to disk. The formula is: (RAM − shared_buffers) / (max_connections × 3). The ×3 factor accounts for multiple operations per query. Setting work_mem too low causes frequent disk sorts (visible as "Sort Method: external merge Disk" in EXPLAIN ANALYZE). Setting it too high risks out-of-memory errors when many connections run complex queries simultaneously.
effective_cache_size Explained
effective_cache_size tells the query planner how much memory is available for caching data files, including both shared_buffers and the OS page cache. It is typically set to 75% of total system RAM. This parameter doesn't allocate memory — it only affects cost estimates, encouraging index scans when sufficient cache is expected.
SSD vs HDD Settings
For SSD storage, random_page_cost should be set to 1.1 (default is 4.0) because random reads on SSD are nearly as fast as sequential reads. This dramatically changes the planner's behavior — it will prefer index scans over sequential scans much more often. effective_io_concurrency should be set to 200 for SSD (default 1), allowing PostgreSQL to issue multiple I/O requests in parallel.
Tuning for Different Workloads
Web applications (Django, Rails, Laravel) typically have many connections (100–500) running simple queries — prioritize higher max_connections and lower work_mem. OLTP workloads need fast single-row lookups — optimize for low latency with checkpoint tuning. Data warehouses run few connections with complex analytical queries — maximize work_mem, maintenance_work_mem, and enable aggressive parallelism.
PostgreSQL on Cloud (AWS RDS, DigitalOcean, Hetzner)
On managed services like AWS RDS, some parameters are set automatically. However, you can still tune work_mem, effective_cache_size, and random_page_cost through parameter groups. On self-hosted servers (DigitalOcean, Hetzner, Linode), use this generator to create a complete postgresql.conf optimized for your instance size.
PGTune vs DevToolKit PostgreSQL Config Generator
Both tools use similar algorithms based on PostgreSQL community recommendations. Key differences: DevToolKit runs 100% in your browser (no data sent to servers), provides explanations for each parameter, generates a copyable configuration block, and shows quick summary cards for key values. PGTune has been the go-to tool for years, but its interface hasn't been updated recently. This generator is a modern, privacy-respecting alternative.
Want to understand each parameter in depth? Read our PostgreSQL Performance Tuning Guide 2026 — complete formulas, recommended values by server size, and best practices.