Your API starts returning timeouts under load, but the database CPU is low and queries look fast. Where do you look?

That combination points to connection pool exhaustion or a similar concurrency limit, not to the database being slow. Check pool wait time and active versus idle connections: requests are queuing for a connection while each holder keeps it too long, often because of a slow external call inside a transaction, a missing timeout, or a leaked connection that is never returned. Fix the holding time first, then size the pool deliberately.

Fast queries plus slow requests means the time is spent waiting for something, and the pool is the usual suspect. I would look at pool wait time and how long connections are held, plus the database side count of active versus idle in transaction sessions. A pile of idle in transaction is the giveaway: something opened a transaction and then did work that is not database work. That is almost always the cause, an HTTP call to a payment provider or a slow serialization step sitting inside a transaction, so each request holds a connection for a second instead of five milliseconds and the pool drains at a fraction of the traffic. The fix is to shorten the critical section: do the external call before or after the transaction, add statement and transaction timeouts, and make sure every path returns its connection even on error. Only then would I touch the size, and carefully, because every instance multiplies it. Raising the pool without fixing the holding time just moves the queue onto the database and turns a slow endpoint into a global outage.