Model, migrate, refresh, and verify PostgreSQL materialized views in Django for expensive report or dashboard queries that can tolerate stale data.
SkillScore100Maintained
Automatic
◆Coding pack
Last verified 8/15/2026
What it changes
Passed 24 of 24 test cases with the skill, and 23 of 24 without it.
Without skill96%
With skill100%
Checks it passed that the model alone missed
Test and prove the materialized view refresh execution.
1 fixed23 passed either way0 still failing0 broke
Pass-rate lift
+4 pp
Tokens
-16%
Agent turns
0%
Response time
-38%
Model gemini-3.6-flashMeasured 8/15/2026v124 of 24 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
What functional check must be executed during staging verification to ensure the materialized view updates as expected when source data changes?
What was checked, without and with the skill
Checked
Without skill
With skill
Test and prove the materialized view refresh execution.
Missed
Passed
case-19 · 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.md39 lines2 files
Django Materialized Views
Use this skill when an expensive read query is reused often and can tolerate controlled staleness. Try query-plan, index, and ORM expression improvements first; materialized views add operational state.
Workflow
Confirm fit.
The source query is expensive and stable.
Consumers can accept stale data.
Refresh cadence, ownership, and failure behavior are clear.
PostgreSQL is the target database.
Design the materialized view.
Define the SQL query and output columns.
Add a unique column or unique column set if concurrent refresh is required.
Add indexes for consumer queries against the view.
Integrate with Django.
Create the view with RunSQL.
Represent it as an unmanaged model with managed = False.
Keep the unmanaged model fields aligned with the SQL output.
Make writes impossible at the application boundary.
Implement refresh.
Use REFRESH MATERIALIZED VIEW for simple refreshes.
Use REFRESH MATERIALIZED VIEW CONCURRENTLY only when the view is already populated and has a qualifying unique index.
Schedule refresh through a management command, task queue, or database job.
See materialized-view-patterns.md for migration, model, and refresh templates.
Safety Notes
A materialized view returns stored data; it is not automatically current.
Concurrent refresh avoids locking out reads but has prerequisites and still allows only one refresh at a time per view.
Refreshing a large view can be a major database workload. Measure it separately from reads.
Verification
Validate the SQL against source tables, test the unmanaged model reads, prove refresh behavior, and measure read latency before/after.