Comprehensive Guide to Postgres Connection & Memory Limits
Understanding and correctly configuring PostgreSQL memory limits is critical for database performance and preventing out-of-memory (OOM) crashes in production. This calculator helps you optimally configure your `max_connections`, `shared_buffers`, and `work_mem` parameters to fully utilize your server's RAM without risking downtime.
Key PostgreSQL Memory Parameters
- shared_buffers: Typically set to 25% of total system memory. This defines how much memory PostgreSQL uses for caching data pages.
- max_connections: Every connection consumes a base amount of RAM (typically 2-10MB). Too many idle connections can drain memory rapidly; using a connection pooler like PgBouncer is often recommended.
- work_mem: The memory used for internal sort operations and hash tables before writing to temporary disk files. Setting this too high with many active connections can quickly exhaust system memory.
Reading the OOM Risk Line
The "Optimal Active" figure uses a simple cores × 4 heuristic — a starting point for how many concurrently active (not idle) connections a CPU-bound OLTP workload can usefully context-switch between per core, not a hard limit. The real ceiling comes from RAM: each connection costs a baseline ~5MB plus its full work_mem allocation if it's mid-sort or mid-hash-join, so maxSafeConnections is (totalRAM - shared_buffers) ÷ (5MB + work_mem). The chart's dashed OOM Risk line marks totalRAM × (1 - shared_buffers%) — the memory ceiling left over after shared_buffers is carved out — and it's why the same work_mem value that's perfectly safe at 50 connections can trigger the Linux OOM killer at 500, especially if several connections happen to run sort-heavy queries simultaneously.