Diagnose and improve slow Django database-backed endpoints with evidence-first profiling, query-plan review, index selection, ORM loading fixes, batching, database-side computation, materialized views, and pagination choices.
SkillScore64Maintained
Automatic
◆Coding pack
Last verified 8/15/2026
What it changes
Passed 14 of 22 test cases with the skill, and 10 of 22 without it.
Without skill45%
With skill64%
Checks it passed that the model alone missed
Routes index creation decisions to django-index-design.
Recommends validating execution plans using QuerySet.explain().
Requires verifying that the slow path remains functionally correct.
and 4 more in the full report
4 fixed10 passed either way8 still failing0 broke
Pass-rate lift
+18 pp
Tokens
-4%
Agent turns
0%
Response time
-31%
Model gemini-3.6-flashMeasured 8/15/2026v114 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
Our profiling shows a single complex SQL query on `orders` taking 3.5 seconds in PostgreSQL, while query counts are low (only 2 queries total). Should we refactor the whole ORM model structure or how should we route this database problem?
What was checked, without and with the skill
Checked
Without skill
With skill
Routes single expensive SQL statement issues to django-query-plan-reading.
Missed
Passed
Routes index creation decisions to django-index-design.
Missed
Passed
case-05 · gemini-3.6-flash · 8/15/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md49 lines2 files
Django DB Performance
Use this as the orchestration skill for Django database performance work. Start with measured evidence, reproduce the slow path, and route to the smallest optimization that changes the measured bottleneck.
Core Workflow
Capture the symptom.
Identify the exact endpoint, command, task, report, or queryset.
Record current wall-clock time, query count, slow SQL, database backend, data volume, and Django version.
Keep the original request parameters or fixture that reproduces the issue.
Profile before changing code.
Use APM traces, database slow-query logs, Django Debug Toolbar, connection.queries, or targeted logging.
If the expensive query is known, use QuerySet.explain() or database EXPLAIN.
For API endpoints, profile serializers and permission checks as well as querysets.
Classify the dominant problem.
Many repeated similar queries: use django-orm-query-optimization.
One or two expensive SQL statements: use django-query-plan-reading and django-index-design.
Large memory use or long loops over querysets: use django-queryset-batch-processing.
Python loops computing counts, totals, flags, or latest related rows: use django-db-side-computation.
Slow aggregate/report query that is acceptable when stale: use django-materialized-views.
Slow or inconsistent list pages: use django-pagination-performance.
Unclear evidence: use django-query-profiling.
Apply one change at a time.
Prefer the narrowest change with a clear expected effect.
Avoid adding indexes, prefetches, or materialized views speculatively.
Confirm that the optimization helps real production-like data, not only tiny fixtures.
Verify and document the result.
Re-run the same request or command with the same parameters.
Compare query count, total DB time, wall-clock time, memory, and query plan.
Keep before/after evidence in the PR or final report.
See diagnostic-flow.md for routing checklists, common symptoms, and before/after evidence templates.
Modern Django Notes
Prefer QuerySet.explain() for ORM query plans before dropping to raw EXPLAIN.
Improve Django and Django REST Framework pagination for large querysets using bounded page sizes, stable ordering, indexed ordering, offset limits, keyset pagination, DRF CursorPagination, and count-query tradeoffs. Use when list pages, admin views, APIs, exports, or infinite scroll become slow, inconsistent, or memory-heavy as result sets grow.