How to Use This Tool
Reserve connections and apply target utilization before translating latency into throughput. Pool size is concurrency, not requests per second; query hold time determines how quickly connections turn over.
Why DB Pool Capacity needs more than a raw total
Running at one hundred percent leaves no room for latency tails or transactions that hold multiple queries. For this page, the useful comparison is planning query throughput, not whichever input happens to be largest. The DB Pool Capacity result answers the decision in the heading and should not be reused as a score for a different workflow.
The exact DB Pool Capacity formula
Throughput equals usable connections ÷ average hold seconds × target utilization. The visible fields are Pool connections, Reserved connections, Average query time and Target utilization. For DB Pool Capacity, read each printed unit before entry and make the values describe one transaction, cohort or reporting window. If those scopes differ, the displayed planning query throughput may be arithmetically valid but operationally meaningless.
Interpreting planning query throughput
Compare this ceiling with peak arrival rate and p95 hold time before increasing the pool. The ten-percent comparison is deliberately narrow: it tests the influence of pool connections and is neither a forecast nor a confidence interval. Preserve the values used, their dates and the resulting decision so a later reviewer can reproduce why DB Pool Capacity supported the choice.
What this DB Pool Capacity model leaves out
Transactions, locks, replicas and application queueing are not modeled. That is where DB Pool Capacity stops being trustworthy. If an excluded factor could reverse planning query throughput, extend the model explicitly or use the authoritative account system instead of hiding the factor inside an unexplained adjustment.
Evidence and independent verification
The reference reviewed for DB Pool Capacity is PostgreSQL — Resource consumption. PostgreSQL — Resource consumption supports the named definition or rule but does not supply private values for planning query throughput. Before acting on the result, reconcile the worked example with the relevant dashboard, invoice, export or measurement.
Private, reproducible calculation
DB Pool Capacity runs its arithmetic in the current browser tab and requests no login or API key. That keeps the DB Pool Capacity inputs away from the site's calculation server, while leaving the user responsible for detecting stale data or a changed platform rule. When an assumption changes, reopen PostgreSQL — Resource consumption and rerun the saved DB Pool Capacity scenario.
Sources & assumptions
Tool Spec v2 · verified 2026-08-20. Platform rules and fees can change; the editable inputs remain authoritative for your account.
Official references
- PostgreSQL — Resource consumption (checked 2026-08-20)
Model assumptions
- Every input covers the same reporting period or cohort.
- Transactions, locks, replicas and application queueing are not modeled.
- The calculator uses only the visible fields and does not fetch account data.
