Database

Database Connection Pool Calculator

Sizes a connection pool from throughput and query time, and warns when it is too big.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Write your workload one setting per line: queries per second, average query ms, app instances, database max connections, database cores.
  2. Use the query time your application measures, not the one the database reports — the difference is network time and it is held by the connection too.
  3. Select Size the pool.
  4. If the result warns that the pool is larger than the cores can use, lower it rather than raising the server limit.

What connection pool calculator does

Connection pools are almost always set to whatever the driver defaults to, and then raised whenever anything is slow. Raising them is the wrong instinct: past the point where every core is busy, extra connections add memory and context switching without adding a single query per second, and latency goes up rather than down. The number you actually need comes from one line of arithmetic — the arrival rate multiplied by how long each query is held — and it is usually much smaller than people expect.

Give this page your queries per second, your average query time, how many application instances you run and what the server limit is, and it returns the pool size per instance and the total, with the working shown. It then checks two things people miss: whether the total leaves any headroom for migrations, admin sessions and a rolling deploy that briefly doubles the instance count, and whether the pool is larger than the server has cores to run. It also names what it cannot see — long transactions and connections held across an external call consume a slot without doing work, and they are the usual reason a correctly sized pool still runs dry.

Frequently asked questions

Because the number of connections you need is the number of queries in flight at one moment, not the number of requests you serve. Eight hundred queries a second, each held for twenty-five milliseconds, is twenty connections busy at any instant. Most pools are set well above what the arithmetic asks for, and the extra slots sit idle until something goes wrong and they all wake up at once.

Past a point it makes them slower. A database server can only genuinely run about as many queries at once as it has cores, plus a little for waiting on disk. Beyond that, extra connections queue inside the database instead of inside the pool, and they do it while holding memory and forcing context switches. Queueing in the pool is cheaper and the latency is easier to see.

Traffic is never flat. The multiplier turns your average rate into a worst-case rate so the pool has slack when a batch job, a retry storm or the start of the business day arrives. Two to three times the average is a reasonable starting point; if you have percentile figures, use the ratio of your p99 to your mean instead.

Almost always because something holds a connection without using it. A transaction opened before an external API call, a session left idle in transaction, or a query whose real hold time is much longer than its average all occupy a slot doing nothing. Look for those before raising the pool — raising it hides the problem and moves the failure somewhere less obvious.