SkillVaultskills Browse all 500 skills

Debugging · Version 1.4.0 · Reviewed 2026-08-02

N+1 Query Detector

Diagnose amplification discovery and eager loading design with evidence, explicit trade-offs, and a verification plan.

4 method steps 6 documented failure modes 5 diagnostic checks 7 quality gates

Finds and fixes query amplification from lazy loading, loops, and serializers, and validates the fix with query counts.

₹149 one-time

Get this skill archive

What this skill helps you do

  • Amplification discovery
  • Eager loading design
  • Query count verification

How N+1 Query Detector works

You provide

Endpoint code, serializers, and query logs

It inspects

Query count as a function of result-set size

It decides

Batched loading or eager loading with column scope

You verify

Query count stays constant as records increase

What it checks first

N+1 Query Detector finds and fixes query amplification from lazy loading, loops, and serializers, and validates the fix with query counts. Use it when the work involves Amplification discovery, Eager loading design, Query count verification.

  1. Query count per request as a function of result-set size — linear growth is the definition of the problem.
  2. Whether the amplification comes from an explicit loop, a serializer, or a lazily evaluated relation.
  3. Whether the fix is eager loading, a batched loader, or a denormalized read model.
  4. The depth of nesting, since a nested relation can produce quadratic rather than linear amplification.
  5. Whether the endpoint is paginated at all, which bounds the worst case.

Failure modes it recognizes

  • A serializer accessing a relation per record, invisible in the controller code that appears clean.
  • A permission or policy check performing its own lookup per record.
  • A computed property triggering a count query for every item in a list.
  • Eager loading applied at one level while a nested association still loads lazily.
  • A batched loader configured per request but instantiated per resolver, defeating batching.
  • A cache lookup per record that is fast in development and network-bound in production.

Answers it will reject

  • Caching the endpoint response to hide the amplification, which preserves the cost on every miss.
  • Raising the database connection pool so the queries run in parallel, which shifts load rather than removing it.
  • Measuring improvement in wall time only, which varies with cache state and hides regressions.
  • Eager loading everything, which trades N+1 for one very large over-fetching query.

Decision rules it applies

  • Assert a maximum query count per request in a test; wall time is not a stable acceptance criterion.
  • Prefer a batched data loader when the access pattern is graph-shaped, and eager loading when it is fixed.
  • Bound every list endpoint with pagination so the worst case is defined.
  • Load only the columns and relations the response actually uses.

Evidence it asks for

  • Log query counts per request in development and fail a test that exceeds the declared budget.
  • Compare query count at two result-set sizes to prove the relationship is constant rather than linear.
  • Inspect the slow-query log for a repeated identical query shape with varying parameters.

The method inside

  1. Establish what is actually true about amplification discovery from the supplied evidence, and mark what is missing.
  2. Identify the mechanism behind eager loading design rather than restating the symptom.
  3. Choose the smallest defensible change for query count verification, weighing impact, confidence, effort, and reversibility.
  4. Update confidence only when evidence changes

Deliverables

  • Amplification discovery assessment
  • Eager loading design decision and action plan
  • Query count verification verification checklist

Evidence requirements

  • Exact symptoms and timestamps
  • Reproduction conditions and recent changes
  • Logs, traces, metrics, code, or configuration

Quality gates

  • Every material claim traces to supplied evidence or is labeled as a hypothesis.
  • The response follows the declared deliverable contract.
  • No execution, access, measurement, or verification is invented.
  • Secrets and personal data are redacted rather than repeated.
  • The user receives a concrete independent verification step.
  • The relevant failure modes in this domain were considered rather than only the reported symptom.
  • No listed anti-pattern was recommended as a solution.

Example task

Input

Our list endpoint takes 8 seconds with 50 records but is fast with 5.

Expected output

Linear scaling with record count is query amplification. The usual source is a serializer touching a relation per record rather than an obvious loop, which is why it survives code review. Count queries per request before and after, and treat the count as the acceptance criterion rather than wall time...

Boundaries and compatibility

Ideal for

  • Amplification discovery: produce a decision or artifact grounded in supplied evidence.
  • Eager loading design: produce a decision or artifact grounded in supplied evidence.
  • Query count verification: produce a decision or artifact grounded in supplied evidence.

Out of scope

  • Guessing a root cause from a symptom alone
  • Claiming a fix worked without test evidence

Agent compatibility

  • GitHub Copilot custom agents
  • Claude Agent Skills / SKILL.md
  • Any instruction-following chat model

Tool policy: Advisory by default. No tools are assumed. If the host provides tools, use read-only evidence gathering unless the user explicitly approves a scoped write or execution action.