Optimize Django ORM query loading by fixing N+1 queries, duplicate related-object queries, over-fetching, serializer/template query loops, and inappropriate select_related, prefetch_related, only, or defer usage.
SkillScore86Maintained
Automatic
◆Coding pack
Last verified 8/16/2026
What it changes
Passed 19 of 22 test cases with the skill, and 18 of 22 without it.
Without skill82%
With skill86%
Checks it passed that the model alone missed
Includes a query-count assertion or focused regression test for the view.
1 fixed18 passed either way3 still failing0 broke
Pass-rate lift
+5 pp
Tokens
-1%
Agent turns
0%
Response time
-26%
Model gemini-3.6-flashMeasured 8/16/2026v119 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
My Django web app has a dashboard view rendering a table of `Order` records. Inside the template loop, I'm displaying the `Customer.name` and `Customer.Profile.avatar` for each order. The database is getting hammered with hundreds of queries. Can you optimize the ORM call in my view? In your response, I need you to demonstrate the exact reduction in database calls, show the duplicated SQL pattern that was occurring, and note any changes in execution speed or RAM usage.
What was checked, without and with the skill
Checked
Without skill
With skill
Applies select_related for the Customer and Profile relationships.
Passed
Passed
Includes a query-count assertion or focused regression test for the view.
Missed
Passed
case-02 · gemini-3.6-flash · 8/16/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md38 lines2 files
Django ORM Query Optimization
Use this skill for query-count and object-loading problems. The usual target is an N+1 pattern where each rendered row or serialized object triggers more database work.
Workflow
Prove the query pattern.
Capture query count and duplicate SQL for the slow path.
Identify the loop, serializer field, template access, admin display, or model property triggering related queries.
Choose the loading strategy.
Use select_related() for single-valued relationships: ForeignKey and OneToOneField.
Use prefetch_related() for many-valued relationships: reverse FK and many-to-many.
Use Prefetch() when the related queryset needs filters, ordering, annotations, or nested select_related().
Use values() or values_list() when model instances are unnecessary.
Use only() or defer() only when large columns are truly unused.
Keep access consistent.
If you prefetch items, do not later call items.filter(...) and expect the prefetch cache to help.
If using iterator() with prefetch_related(), provide chunk_size.
Avoid putting broad prefetches into default managers unless every caller needs them.
Add a focused regression check when useful.
Use a query-count assertion around the exact view or serializer path.
Avoid brittle global query-count tests.
See relationship-and-column-loading.md for examples and review cues.
Anti-Patterns
Adding prefetch_related() to every queryset without checking memory.
Using only() and then touching deferred fields in a loop.
Optimizing a queryset but leaving serializer method fields to issue per-row queries.
Hiding queries in __str__(), model properties, template includes, or admin list methods.
Verification
Show the query count and duplicate-query pattern before and after, plus any wall-time or memory change.