PostgreSQL Connection Pool Sizer
Calculate optimal max_connections, work_mem, and PgBouncer configuration for your server. Get a ready-to-paste postgresql.conf snippet.
Total across all application instances
# postgresql.conf — generated by duckkit.dev/tools/db-connection-pool
# Server RAM: 16GB | Workload: OLTP
# Connection settings
max_connections = 20
# Memory settings
shared_buffers = 4GB
work_mem = 204MB
maintenance_work_mem = 819MB
# Query planner hint (not actual allocation)
effective_cache_size = 12GB
# Write-ahead log
wal_buffers = 16MB
checkpoint_completion_target = 0.9
# Parallel query (adjust based on CPU cores)
max_worker_processes = 8
max_parallel_workers_per_gather = 4
max_parallel_workers = 8Why max_connections is not free
Every PostgreSQL connection is a full OS process. Even when completely idle, a connection consumes resource metadata and shared memory slots, equating to approximately 2-5MB of RAM per connection. When active, each running query requests exactly what it needs from work_mem, which means 500 connections executing complex sorts can easily wipe out your memory limits. This is exactly why keeping max_connections artificially high is dangerous.
Transaction vs session pooling
Your choice of connection pooler greatly dictates its efficiency. In session mode, a pooler ties its backend server connection to a client for the entire duration of the client connect. This is functionally similar to a direct database connection minus process startup time.
In transaction mode, however, a server connection is assigned to a client only during an active transaction and released immediately after. This multiplexing method can allow 100 actual PostgreSQL connections to handle 5,000+ client application connections seamlessly.
The work_mem trap
A common mistake is configuring work_mem to be too large. Remember that work_memis allocated per sort/hash operation, not per query. A parallelized query with multiple joins might invoke 5-10 operations simultaneously, multiplying the memory allocated. This multiplicative effect is the primary cause of out-of-memory (OOM) crashes under sudden load spikes.
When to add PgBouncer
As a strict rule of thumb, you should strongly consider PgBouncer or Odyssey once your application scale requires more than 50-100 max_connections on your database server. By reducing the number of idle server processes, PostgreSQL requires less context switching and runs considerably faster.
See how PostgreSQL latency fits your overall system budgetLearn more about PgBouncer