Your database is fast and your API is slow. Both can be true at once, because most of a request's life happens outside the database.
A query timer starts when the statement reaches the engine and stops when the last row comes back. Everything around it is invisible to that number: waiting for a free connection in the pool, turning rows into objects, serializing them, compressing, handing bytes to a proxy, then pushing those bytes across whatever network the client is actually sitting on.
The wire is where API latency hides most often. A response the server finishes in milliseconds can land seconds later at the client if it carries a deeply nested payload over a mobile link. The server measures time to first byte. The user lives with time to last byte. No database dashboard knows the difference between the two.
In payment integrations this shows up as an argument nobody can win: the merchant reports a slow endpoint, my own logs show a fast one, and both parties are telling the truth. The query was never the subject.
So I budget latency per response rather than per query. Response size in bytes, per endpoint. Serialization time instrumented separately from data access. Time to last byte measured at the edge, not in the handler. Once those three numbers exist, trimming fields and paginating stop being cosmetic cleanups and become performance decisions with a known payoff.
The other gaps in that chain (pool checkout, proxy buffering, serialization cost) I write up in more depth on my blog: https://polycratia.com/c/b5cfa43b
If you've chased this before, you probably already know which gap turned out to be yours: the pool, the serializer, or the bytes...