This is a practical integration post, not a benchmark flex.
The problem
Two different failures look the same in user land:
- One query is genuinely slow.
- Every query is "fine", but a single HTTP request executes dozens of them.
Traditional "log slow queries" tooling often optimizes for (1). It is easy to miss (2) until p95 latency jumps.
What queryd does
@olegkoval/queryd is a small library that wraps the boundary where your app talks to the database:
- Slow query warnings via a configurable threshold.
-
Optional per-request budgets (query count + total time) when you run work inside
runWithDbContext. - Structured events you can forward to your logger or APM adapter.
It is driver-agnostic for common patterns (wrapTaggedTemplate, wrapQueryFn) and has an optional Prisma entry: @olegkoval/queryd/prisma.
Minimal example (postgres.js-style tagged template)
The README quick start is the source of truth; the idea is:
- Create a
SlowQueryDetectorwith thresholds + optionalrequestBudget. - Wrap your
sqltagged template withwrapTaggedTemplate. - Wrap request work with
runWithDbContext({ requestId, ... }, async () => { ... }).
Full copy-paste code lives here:
https://github.com/oleg-koval/slow-query-detector#60-second-quick-start
When not to use it
- If you already have end-to-end tracing + query instrumentation you trust, you may not need another layer.
- If you want a hosted UI and retention analytics, this is not that — it emits events; you choose the sink.
Call to action
Try the quick start on a branch and tell me where wrapping gets awkward:
https://github.com/oleg-koval/slow-query-detector/issues/new?template=integration-feedback.md
Top comments (0)