Your database is fast. Your request is not, because it asks the fast thing hundreds of times.
Per-query metrics are the best alibi in backend engineering. Every statement comes back in milliseconds, the slow query log is empty, the dashboard is green, and the endpoint still takes a second. Nobody can point at the line that costs you that.
The mismatch is in the unit. The database measures queries. The user experiences a request. In between sits a multiplier that no database dashboard tracks: round trips per request.
You see it most in catalog and marketplace code. A list endpoint loads products in one clean query, then resolves a delivery rate per item, then a permission check per item, then a translation or price lookup per item. Each call is honest and fast. Together they are the latency.
Serialization hides the same shape. Nested objects get assembled lazily, so the query count becomes a property of the response tree and not of the handler you can actually read.
What works for me: log round trips per request next to duration, and give every endpoint a budget. A handler that quietly goes from a handful of queries to dozens should fail review the way a slow query would. Fast per unit is not fast per request.
I write more about this kind of production latency work here: https://polycratia.com/c/e398ba92
Worth finding where your own query count quietly explodes: serializers, permission checks, per-item enrichment...