A fast database is one of the main reasons an API stays slow.
No paradox there. Slow-query logs are duration instruments: they catch the one call over a threshold and stay blind to the thousand under it. When every query comes back in single-digit milliseconds, nothing crosses the line, so the cost moves out of duration and into count, where nothing is watching.
The mechanics are arithmetic. Request latency is per-call cost times call count, plus whatever assembly happens around it. Fast storage shrinks the first term and makes the second one invisible. A catalog endpoint that fans out one query per item, plus one per price, plus one per delivery option, can burn most of a request budget inside a database whose own dashboard reads green at p99.
It repeats a layer up: serializers that touch related objects, permission checks resolved per row, a cache lookup per entity over a network hop. Each one is cheap. None of them gets logged. All of them are serial.
So I treat queries-per-request as a first-class metric next to latency: counted per endpoint, attached to the request log, given a budget that fails loudly in tests when it drifts. Probably the cheapest instrument I know for catching a regression no duration threshold will report.
I write more about where request latency actually hides over on my blog: https://polycratia.com/c/50347654
Worth knowing where your own query count drifts fastest, in serializers, in permission checks, or in those per-row cache lookups...