Full round replay — connection pool sizing

Pass: Almost certainly too big. It implies either enormous throughput or a long hold time, and the second is far more common. What is the hold time?

Fail: Says it depends, or accepts it.

Pass: A pool is a concurrency limit, not capacity. Past what the database can genuinely run at once, more connections add lock contention, cache churn and context switching — and move the queue from the application, where it is visible and can shed load, into the database, where it is not.

Fail: Thinks more connections always means more throughput.

Pass: Hold time. The same pool of twenty serves ten thousand requests a second at a 2ms hold and a hundred at 200ms. Almost nobody measures it, because it covers everything between getConnection and close rather than just query execution.

Fail: Says pool size, or throughput.

Pass: Requests fail at acquisition with a pool timeout, before touching the database — in HikariCP, a SQLTransientConnectionException saying the request timed out. The database may be entirely idle while it happens.

Fail: Expects a database error or a slow query.

Pass: At my own code. Something is holding connections rather than something being slow — usually a remote call inside a transaction, or a close() that sits after code which can throw. HikariCP's leak-detection-threshold logs a stack trace naming the holder.

Fail: Investigates the database.

Pass: No — that queues instead of shedding load, so requests pile up until callers give up first and the queued work is wasted. A short timeout refuses some requests immediately, which beats making all of them slow.

Fail: Raises it to stop the errors.

Pass: Smaller than for one, and the number that matters is the total: instances times pool, plus batch workers, admin tools and monitoring, against max_connections. Autoscaling silently multiplies the first term.

Fail: Gives a per-instance number with no total.

Pass: Past a few hundred connections, or with elastic instance counts. In transaction mode it multiplexes many client connections onto few server ones, and session-level state does not survive — prepared statements, temporary tables, advisory locks, session SET.

Fail: Proposes it with no caveats, or has not heard of it.

Pass: Not the arithmetic. A platform thread pool used to cap database concurrency as a side effect; virtual threads remove that, so ten thousand tasks can reach for a pool of ten. The pool becomes the only backpressure, which makes the acquisition timeout a load-shedding decision.

Fail: Says virtual threads fix pool contention.

Pass: leak-detection-threshold. It costs nothing and answers the question the whole topic turns on — what is holding connections — with a stack trace instead of a theory.

Fail: Changes the pool size before measuring anything.