PostgreSQL max_connections & memory calculator
Enter your instance RAM and work_mem to get a memory-safe max_connections, shared_buffers, and effective_cache_size - see exactly where your RAM goes, and copy a ready-to-paste postgresql.conf. Deterministic, and 100% in your browser.
- Runs in your browser No server round-trip
- No sign-up Nothing to install
- Nothing is uploaded Your SQL never leaves the tab
- Works offline After the page loads
How the 8 GB is budgeted
postgresql.conf
# postgresql.conf - starting point for 8 GB RAM
shared_buffers = 2GB
effective_cache_size = 5734MB
maintenance_work_mem = 512MB
work_mem = 4MB
max_connections = 321Starting points based on community rules of thumb. Benchmark against your real workload and adjust.
Where your PostgreSQL memory actually goes
shared_buffers - Postgres's own cache
About 25% of RAM. This is the buffer pool Postgres manages directly. The rest of your RAM isn't wasted - the operating system caches data files too, which is why effective_cache_size is set much higher.
Per-connection memory
Each backend uses a base amount plus work_mem for every sort or hash in its current query. A complex analytics query can consume work_mem several times at once, so heavy workloads support far fewer connections than light ones.
effective_cache_size - a planner hint
This doesn't allocate memory; it tells the query planner how much cache (shared_buffers + OS page cache) is likely available, so it can favour index scans when data is probably cached. Set it to ~70% of RAM.
maintenance_work_mem - for housekeeping
Used by VACUUM, CREATE INDEX, and ALTER TABLE. It can be larger than work_mem because only a few run at once. A common setting is RAM/16, capped around 1-2 GB.
The connection ceiling
Take RAM, subtract shared_buffers and OS headroom, divide by per-connection memory. That's your safe max_connections. Exceeding it doesn't fail gracefully - it can trigger the OOM killer under load.
Why a pooler changes the math
A pooler lets Postgres keep a small, memory-safe max_connections while serving thousands of clients. On small instances it's not optional - it's how you avoid choosing between concurrency and stability.
max_connections & memory FAQ
How do I choose a safe max_connections for PostgreSQL?
Work backwards from memory. Reserve about 25% of RAM for shared_buffers and some headroom for the OS, then divide what's left by the memory a busy connection uses (roughly work_mem times the sorts a query runs, plus ~10 MB overhead). The result is the number of connections your RAM can actually support. Setting max_connections higher than that invites out-of-memory crashes under load.
What should shared_buffers be set to?
The long-standing guideline is 25% of system RAM, up to a point (very large machines see diminishing returns past ~8-16 GB). shared_buffers is PostgreSQL's own cache; the OS page cache handles the rest, which is why effective_cache_size is set higher (~70% of RAM) to tell the planner how much cache is really available.
Why does a high max_connections hurt performance?
Each connection is a separate backend process that reserves memory (including work_mem headroom for its queries) and adds scheduling and lock-management overhead. A large max_connections wastes RAM even when idle and lets a connection storm exhaust memory. It's better to keep max_connections modest and use a connection pooler to serve high concurrency.
What is work_mem and how does it affect connections?
work_mem is the memory each sort or hash operation may use before spilling to disk. A single complex query can use it several times over (multiple sorts/hashes), and every connection running such a query multiplies it. That's why raising work_mem forces max_connections down - the two trade off against each other for a fixed amount of RAM.
When should I add a connection pooler instead of raising max_connections?
Almost always, once you need more than a couple hundred concurrent clients. A pooler like PgBouncer multiplexes many client connections onto a small server pool, so Postgres stays within a memory-safe max_connections while your app scales. Use the pool-size calculator to size it.
Related developer tools
More free, browser-only tools for PostgreSQL and cloud storage.
Paste an EXPLAIN ANALYZE plan and get an interactive tree, slow-node highlighting, row-estimate checks, and plain-English fixes.
Open toolBuild or decode a DATABASE_URL and generate ready-to-paste snippets for Node, Python, Go, Rust, Java, and PHP.
Open toolTurn CPU, RAM, and workload into a safe pool_size, max_connections, PgBouncer mode, and timeouts - with the math shown.
Open toolCompare AWS S3, Cloudflare R2, Backblaze B2, Google Cloud, Azure, and Supabase side by side - storage, egress, and requests, with charts.
Open toolRight-sized Postgres, without the tuning.
Swyftstack provisions PostgreSQL with sensible memory defaults and pooling built in. Deployed in under a minute - no postgresql.conf required.