Your database being fast is the reason nobody finds the slow part.
Most API latency is not work. It is waiting for a slot.
A request needs a connection from the pool. The query itself finishes in single-digit milliseconds, but if the handler keeps that connection checked out while it calls a payment provider, a verification vendor, or pushes a file to object storage, the slot is held for the whole round trip. Throughput then caps out at pool size divided by hold time, and query speed has little to do with it. Past that line every additional request queues, and queue wait does not show up on the database dashboard: query time stays green while p99 climbs.
The worst version is an open transaction wrapped around an external call. A vendor timeout is now holding locks, and the retry lands before the first attempt has let them go.
How I approach it: a connection gets checked out around database work only. External calls happen outside the transaction, with the request state persisted first and an idempotency key carrying it, so the write is replayable instead of being held open. Background workers get their own pool, so a batch job cannot starve the request path.
Instrument hold time per request, not query time. That is where the time goes.
Next time you chase a slow endpoint, check whether it was query time or connection wait...