A team doubled maximum-pool-size to 50 after a connection-pool-exhaustion incident and it didn't help. Why not, and what does close() on a pooled connection actually do?

Past the database's actual parallelism (roughly cores × 2 plus spindle count, for the whole database across every service, not per service), more connections don't mean more concurrent work getting done — the extra connections context-switch and contend for the same buffers and locks, and each individual query finishes later. Exhaustion is almost always caused by hold time (how long each borrowed connection is kept, per Little's law: connections in use = request rate × hold time), not by an insufficient pool size, so doubling the size just lets more slow requests pile up against the same database bottleneck instead of fixing what made them slow. Separately, close() on a pooled connection doesn't close the socket — it resets tracked JDBC-level state (rolls back any open transaction, restores auto-commit and isolation level) and returns the connection to the pool for reuse.