Connection Pool Tuning: Application Side

Database pool tuning gets attention; app-side pool tuning rarely does. Both matter; the app side is often where the real wins are.

Why app-side matters

Database accepts; the pool is what your app actually uses.

App pool too small: queueing inside your service; throughput limited.

App pool too large: starves the DB.

Four numbers per app

• 1. Min connections.
• 2. Max connections.
• 3. Acquire timeout.
• 4. Idle timeout.

Per-language defaults

Hibernate: 10/20 default. Often too small.

HikariCP: 10 default. Tune to workload.

psycopg2: no pool by default. Use pgbouncer or sqlalchemy.

Each language ships defaults that worked for the author; not for you.

Metrics to watch

Pool used / max ratio. Acquire wait time p99. Connection age.

Trending up = pool too small; trending flat at max = throughput bottleneck.

Antipatterns

• Default pool forever. Misses workload.
• No metrics. Discovery via incident.
• Pool size = max DB connections / 1. Ignores other apps.

What to do this week

Three moves. (1) Apply this pattern to your slowest production endpoint. (2) Measure p99 before/after. (3) Document the win and ship the runbook so the team can reproduce.