A fast database does not give you a fast API. Query time is the slice of the latency budget you actually control, and most of that budget belongs to systems you don't own.
Look at where a request in a payments or marketplace backend spends its time. A checkout call quotes rates from several carriers. A signup call waits on a KYC provider's decision. A payout call waits on a payment provider that is quick on a good day and tells you nothing on a bad one.
Each of those is a network round trip to an endpoint with its own load and its own queueing, plus an incident you will never be told about.
Serialize three of them and your median is the sum. Your tail is whichever dependency is having a bad afternoon.
Then the blocking spreads. A worker waiting on an external response still holds its slot, and often still holds its database connection. One slow provider quietly turns into a globally slow API, while the database dashboard stays green: which is probably why people keep optimizing the one layer that was never the problem.
The fix is a boundary, and no index will get you one. Decide explicitly what the request path is allowed to wait on. Everything else gets a timeout you chose, or a fallback answer, or a pending state that reconciles asynchronously. Cache what is stable: carrier rates change far more slowly than checkouts happen. And measure latency per dependency instead of as one number, or you average the problem away.
I write up more production trade-offs like this one at https://polycratia.com/c/4cbf07a8
Worth knowing where the time actually went, the last time you chased a slow endpoint...