Database Connection Pool Size Calculator

Enter your database server's CPU cores, storage type and max_connections, then your application's instance count, threads, average query latency and target throughput. The calculator applies the HikariCP / PostgreSQL wiki formula (cores × 2 + effective spindles) for the per-database optimum, Little's Law (throughput × latency) for per-instance demand, and checks the total against max_connections and a rough per-backend memory estimate. Every intermediate number and the bound that won are shown, so nothing is a black box. You get a ready config snippet for HikariCP, pgxpool, node-postgres, SQLAlchemy, Django or PgBouncer, plus the PostgreSQL-side SQL to verify and monitor. Everything runs entirely in your browser — nothing is sent to a server.

Database server

CPU coresStorageRAM (GB)max_connectionsReserved (superuser)work_mem (MB)

Application

App instances / podsThreads / workers per instanceAvg query latency (ms)Target queries/sec per instancePgBouncer (transaction mode) in front?

Config snippet for

Recommendation

Verdict: set each of your 4 app instance(s) to a pool of 5 connection(s) (20 total). The binding constraint was per-database share and Little's Law × 1.5 (tie).
Total demand 20 fits within the 97 available connections (21% of headroom used).

Step 1 — per-database optimum (HikariCP / PostgreSQL wiki)
  pool_size = cores × 2 + spindles  = 8 × 2 + 1 = 17
  storage                           = SSD / NVMe (spindles treated as 1)

Step 2 — Little's Law per instance (L = λ × W)
  throughput × latency              = 500 qps × 5 ms = 2.50 → ceil 3
  with 1.5× safety, min 2           = max(2, ceil(3 × 1.5)) = 5

Step 3 — per-instance pool = min(share, threads, Little's Law)
  share = ceil(optimum / instances) = ceil(17 / 4) = 5
  threads per instance              = 20
  Little's Law × 1.5                = 5
  recommended per instance          = min(5, 20, 5) = 5
  bound that won                    = per-database share, Little's Law × 1.5

Step 4 — total demand vs max_connections
  total demand                      = 5 × 4 = 20
  available                         = 100 − 3 reserved = 97
  server-side connections           = 20
  status                            = OK

Step 5 — memory estimate (rough; per backend ≈ 5–10 MB + work_mem × 2)
  per backend                       ≈ 13 MB – 18 MB  (work_mem 4 MB × 2 nodes)
  20 server connections             ≈ 260 MB – 360 MB
  all 100 max_connections           ≈ 1.3 GB – 1.8 GB  (5.5% of 32 GB at the high end)
  This is an estimate. Real usage depends on plan shape, temp buffers, and shared_buffers is not included.

Config snippet

# HikariCP (application.properties) — one app instance
spring.datasource.hikari.maximum-pool-size=5      # per-instance pool; 4 instances → 20 total
spring.datasource.hikari.minimum-idle=5           # Hikari recommends minimumIdle = maximumPoolSize (fixed-size pool)
spring.datasource.hikari.connection-timeout=30000    # ms to wait for a free connection before throwing
spring.datasource.hikari.idle-timeout=600000         # 10 min; only matters when minimum-idle < maximum-pool-size
spring.datasource.hikari.max-lifetime=1800000        # 30 min; keep below any DB/proxy-side connection limit
spring.datasource.hikari.keepalive-time=300000       # 5 min; prevents idle connections being dropped by firewalls
spring.datasource.hikari.pool-name=app-pool

// Java equivalent
HikariConfig cfg = new HikariConfig();
cfg.setJdbcUrl("jdbc:postgresql://db:5432/app");
cfg.setMaximumPoolSize(5);
cfg.setMinimumIdle(5);
cfg.setConnectionTimeout(30_000);
cfg.setIdleTimeout(600_000);
cfg.setMaxLifetime(1_800_000);

PostgreSQL side

-- No max_connections change recommended for these inputs.

SHOW max_connections;
SHOW superuser_reserved_connections;   -- also reserved_connections on PG 16+
SHOW work_mem;

-- Who is actually holding connections right now?
SELECT application_name,
       state,
       count(*)                                   AS conns,
       max(now() - state_change)                  AS longest_in_state
FROM   pg_stat_activity
WHERE  backend_type = 'client backend'
GROUP  BY application_name, state
ORDER  BY conns DESC;

-- Headroom check
SELECT current_setting('max_connections')::int                       AS max_connections,
       (SELECT count(*) FROM pg_stat_activity)                       AS in_use,
       current_setting('max_connections')::int
         - (SELECT count(*) FROM pg_stat_activity)                   AS free;

-- Kill connections stuck idle in transaction (adjust the threshold first)
-- SELECT pg_terminate_backend(pid) FROM pg_stat_activity
-- WHERE state = 'idle in transaction' AND now() - state_change > interval '5 min';

-- Note: changing max_connections requires a full PostgreSQL restart; it also
-- affects shared memory sizing, so bump it in steps rather than to 1000 at once.

Notes

• More connections do not mean more throughput. Past cores × 2 + spindles, extra backends only add context switching and lock contention; a smaller pool with a queue usually finishes the same work faster.
• On SSD/NVMe the 'spindle' term is close to 1 because there is almost no seek wait; the formula becomes ≈ cores × 2 + 1. If your workload is dominated by long-running analytical queries the optimum is lower, not higher.
• Watch for 'idle in transaction' sessions in pg_stat_activity — they hold a connection (and locks) without doing work. Set idle_in_transaction_session_timeout and fix the code path that leaves transactions open.
• Pooler modes matter: PgBouncer session mode gives no multiplexing; transaction mode returns the server connection after each transaction but breaks session state (SET, prepared statements, advisory locks) unless you plan for it.
• Serverless and autoscaled apps spike connection counts: 200 lambdas × pool of 5 = 1000 connections. Use a pooler (PgBouncer, RDS Proxy, Neon/Supabase pooler) and keep per-function pools at 1.
• The memory estimate here excludes shared_buffers and temp_buffers; measure with pg_stat_activity plus OS-level RSS before trusting any number to the megabyte.

Do more than database connection pool size calculator — meet Chat2DB

Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.

How to use

Fill in the database server section (cores, storage type, RAM, max_connections, reserved connections, work_mem) and the application section (instances, threads, latency, throughput, whether PgBouncer is in front).
Read the Recommendation block: it shows the per-database optimum, the Little's Law demand, the per-instance pool and which bound limited it, plus warnings if total demand exceeds max_connections.
Pick your pool library to get a copy-ready config snippet, then run the PostgreSQL-side queries to confirm the live connection count and spot idle-in-transaction sessions.

Frequently asked questions

What is the formula for database connection pool size?

The most cited rule, from the PostgreSQL wiki and the HikariCP 'About Pool Sizing' page, is pool_size = CPU cores × 2 + effective_spindle_count, where the spindle count is roughly 1 on SSD/NVMe. This is the optimum for the whole database, not per application instance: divide it across instances, and cap each instance by its thread count and by Little's Law (throughput per second × average latency in seconds). A 8-core SSD server therefore wants about 17 concurrent connections total, even if you have 40 app pods.

Why does a smaller connection pool often perform better than a larger one?

A database core can only execute one query at a time; extra connections just wait on CPU, locks and I/O while consuming memory (each PostgreSQL backend is a process using roughly 5–10 MB plus work_mem per sort or hash node). With too many connections the server spends its time context switching and contending for buffers, so latency rises and throughput drops. A small pool with a client-side queue delivers the same work with lower tail latency and predictable memory.

How do I check whether my pool size is correct in production?

Query pg_stat_activity grouped by application_name and state: if you see many 'idle' connections you are over-provisioned, if clients wait on connectionTimeout while the server is mostly idle the pool is too small, and any 'idle in transaction' rows point to a code bug. Also compare pool wait time from your driver's metrics against query latency. Chat2DB lets you watch pg_stat_activity and pool metrics live with AI-assisted SQL and charts: download it at https://chat2db.ai/download or use the web version at https://app.chat2db.ai.