Your database can be fast while your API stays slow: "fast" is a per-query average, and latency is a sum.
One request is rarely one query. It is a serial chain: an auth lookup, a permission check, the main read, a few enrichment reads, a cache miss, maybe a carrier or provider call, then serialization. Each link is defensible on its own. The response is their total.
That math is unforgiving in two ways.
First, tails compose. If one step is slow one time in a hundred and an endpoint touches eight steps, the endpoint is slow far more often than any step is. The p99 of a dependency turns into the p50 of the endpoint built on top of it.
Second, round trips are mostly fixed cost. A 2 ms query sitting behind a millisecond of network and pool overhead is a 3 ms step. Fifty of those in a loop is time no query dashboard will flag, because every single query really was fast.
So per endpoint I would track something other than query time: how many sequential round trips it makes, and how many of them genuinely need to be sequential. In my experience most enrichment calls do not, they wait on each other out of code structure rather than data dependency. Batching them, or running them concurrently, recovers more than another index will.
Database metrics measure the parts. Latency is a property of the composition, and nobody owns it until someone sets a budget per endpoint and defends it in review.
If you cap one thing per endpoint, the real choice is milliseconds or round trips...