Developer tools · Capacity
Connection pool size calculator.
The classic cores times two plus spindles formula, split across your app instances.
Inputs
Pool size
Enter the values.
What is the formula for database connection pool size?
The PostgreSQL wiki gives a starting point of "somewhere near ((core_count * 2) + effective_spindle_count)" connections for the whole database. The core count should not include hyperthreading threads. The spindle count is the number of disks the active data is spread over; it is zero if the active data set is fully cached (HikariCP wiki). The wiki notes that no analysis has been done on how well the formula holds for SSDs, so treat the result as a starting value to load-test, not a rule.
Worked example. A 4-core server with 1 effective spindle gives 4 x 2 + 1 = 9 connections in total. Shared by 3 application instances, each pool should be 3.
The result is the total across all clients, not per instance. A small pool that keeps the database busy beats a large one that causes context switching and lock contention; queue the excess in the application or use an external pooler such as PgBouncer.
Frequently asked questions
What is the best connection pool size for PostgreSQL?
The PostgreSQL wiki suggests starting near (core_count * 2) + effective_spindle_count, counting physical cores only, then adjusting by load testing.
Should the pool size count hyperthreads?
No. The wiki says the core count should not include hyperthreading threads even when hyperthreading is enabled.
Does the formula work for SSDs?
The wiki states that there has been no analysis of how well it works with SSDs, so use it as a starting point and test with your workload.
Is the pool size per application instance?
No, the formula sizes the total connections to the database. Divide it by the number of instances, or put a pooler in front so the instances share one pool.
Sources
Checked
The formula and its hyperthreading and SSD caveats are quoted from the PostgreSQL wiki page; the statement that effective spindle count is zero when the active data set is fully cached is from the HikariCP wiki. The per-instance split is plain division. Runs entirely in your browser. Nothing you type is sent or stored.
Scope
Planning estimates, not guarantees. Real systems add overhead this model leaves out and behave differently under load. Measure on your own data and load-test before committing to a design or a bill.