Developer pack
Claude Skill
Postgres Performance Reviewer
Reviews Postgres queries, schema, and indexes against the rules that move latency — missing indexes, N+1, RLS cost, connection limits.
What it does
Audits SQL queries, schema design, and indexing against a prioritized Postgres performance rule set — query performance, connection management, RLS/security, locking — and rewrites the slow paths with EXPLAIN-grounded fixes. Works for any Postgres, with specific notes for Supabase setups (row-level security, connection pooling).
When to use
- ✓A query is slow or database latency is climbing
- ✓Designing schema or choosing indexes for a new feature
- ✓Reviewing RLS policies that may be quietly expensive
- ✓Hitting connection-pool exhaustion under load
When not to use
- ✗The database isn't Postgres — the specifics won't transfer
- ✗The bottleneck is in app code, not the database
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/postgres-performance-reviewer.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
SKILL.md
---
name: postgres-performance-reviewer
description: Use when writing, reviewing, or optimizing Postgres queries, schema, or indexes. Triggers on "slow query", "missing index", "seq scan", "RLS is slow", "connection pool exhausted", "EXPLAIN", or a Postgres performance review.
---
# Postgres Performance Reviewer
Most Postgres slowness comes from a handful of structural causes: a missing or wrong index, a query shape the planner can't optimize, RLS policies re-evaluated per row, or connections used up. Always ground a diagnosis in `EXPLAIN (ANALYZE, BUFFERS)` — read the plan, don't guess.
## Review in priority order
1. **Query performance (critical).** Look for seq scans on large tables, missing indexes on filter/join columns, and functions wrapped around indexed columns (which defeat the index). Consider partial and composite indexes for the actual query shape. Confirm every fix against the query plan.
2. **Connection management (critical).** Postgres connections are expensive and finite. Use a pooler (e.g. PgBouncer / Supabase pooler) for serverless or high-concurrency workloads; long-lived direct connections exhaust the limit fast.
3. **Security & RLS (critical).** RLS policies run per row — a subquery or function call inside a policy can turn a fast read slow. Keep policy predicates index-friendly and cheap; wrap `auth.uid()`-style calls so they evaluate once, not per row.
4. **Schema & locking (high/medium).** Right-size column types, index foreign keys, and watch for migrations or queries that take heavy locks on hot tables.
## Method
- Get the query and its `EXPLAIN (ANALYZE, BUFFERS)` output before recommending anything.
- Propose the index or rewrite, then show the expected plan change (seq scan → index scan, rows estimate, cost).
- Note any Supabase specifics (pooler endpoint, RLS evaluation) when relevant.
## Anti-patterns
- Adding indexes by guess without reading the query plan
- An index on a column that's always wrapped in a function in the `WHERE`
- Expensive subqueries or function calls inside an RLS policy, re-run per row
- Direct long-lived connections from serverless functions instead of a pooler
- Over-indexing — every index slows writes; index for the queries you actually run
Example prompts
Once installed, try these prompts in Claude:
- This query does a seq scan on a 2M-row table and takes ~3s. Diagnose it and add the right index.
- Reads got 5x slower after we enabled row-level security. Review our RLS policies for cost.