Sql Query Reviewer

The Problem

A pull request lands with a new data-access query. It passes all tests because the test database has 50 rows. In production with 2M rows, the correlated subquery executes once per row and the endpoint times out. Meanwhile, a string-interpolated LIKE clause creates an SQL injection vector that the SAST tool doesn't flag because it's inside an ORM raw query. Three weeks later, the compliance audit catches the SELECT * pulling password hashes into an API response. None of these issues would have survived a proper review — but nobody on the team has a systematic checklist for SQL.

What You Get

• Security audit covering SQL injection detection (string concatenation, format strings, template literals), privilege escalation (UPDATE/DELETE without WHERE), PII exposure in SELECT clauses, multi-statement injection vectors, and view-based security bypass
• Performance analysis flagging N+1 query patterns across Django, SQLAlchemy, Prisma, ActiveRecord, and Sequelize — with the exact ORM-specific fix (select_related, joinedload, include, etc.) for each case
• Index usage evaluation identifying WHERE clauses on unindexed columns, function-wrapped indexed columns, leading wildcards in LIKE, implicit type conversions, and OR-across-column anti-patterns — with suggested index additions
• Correctness checks for NULL handling (IS NULL vs = NULL), division by zero, OFFSET pagination on large tables, non-deterministic LIMIT without ORDER BY, race conditions (TOCTOU patterns), and upsert conflict target correctness
• EXPLAIN ANALYZE interpretation mapping PostgreSQL Seq Scan, Nested Loop, MySQL filesort, and temp table warnings to specific remediation actions with severity ratings
• Language-specific pitfall patterns for Python (Django/SQLAlchemy), JavaScript/TypeScript (Prisma raw), Ruby (ActiveRecord), and Go (database/sql) — each showing the dangerous pattern and the parameterized fix

Why This Beats Prompting It Yourself

When you ask an LLM to "review this SQL," it identifies the obvious issues (SELECT *, missing WHERE) but misses the subtle ones: a correlated subquery that executes O(n²) on a 1M-row table, an implicit varchar-to-int conversion that prevents index usage, or a LEFT JOIN where the WHERE filter effectively converts it to an INNER JOIN. This skill provides a systematic four-pillar framework (security → performance → correctness → maintainability) with severity matrices that prioritize which issues to fix first — not a scattershot of observations.

Example Session

You: "Review this ORM query — it's fetching users with their posts for a dashboard."

users = User.objects.filter(status='active')
for user in users:
    recent_posts = Post.objects.filter(
        author=user, created_at__gte=week_ago
    ).order_by('-created_at')[:5]
    user.recent_posts = list(recent_posts)

Agent output:

SQL QUERY REVIEW — User Dashboard Query
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[HIGH] N+1 Query Pattern Detected
  The loop fires one Post query per active user.
  If 5,000 users are active, that's 5,001 database queries.
  Fix: Use prefetch_related with a custom queryset:
    users = User.objects.filter(status='active').prefetch_related(
        Prefetch('post_set', queryset=Post.objects.filter(
            created_at__gte=week_ago
        ).order_by('-created_at')[:5])
    )

[MEDIUM] Missing Index on Post(author, created_at)
  EXPLAIN would likely show Seq Scan on post table.
  Fix: Add composite index:
    CREATE INDEX idx_post_author_created ON posts(author_id, created_at DESC);

[LOW] Filtered Query Slicing
  [:5] on a filtered queryset works but may produce inconsistent results
  if posts are created between filter execution. Use explicit ordering.

VERDICT: 1 HIGH, 1 MEDIUM, 1 LOW — fix N+1 before merge.

Use Cases

• Pull request review for any SQL, ORM query, migration, or data-access code change
• Pre-production performance audit when queries will run against large datasets
• Security review of user-facing endpoints that accept search, filter, or sort parameters
• Post-incident debugging when a query causes database load spikes
• Training junior developers on SQL anti-patterns specific to their ORM of choice

Known Limitations

The reviewer analyzes query patterns statically; it cannot run EXPLAIN ANALYZE against a live database. For queries touching >10K rows, the skill will recommend running EXPLAIN ANALYZE manually and interpreting the plan using the provided red-flag reference table. The severity ratings assume standard OLTP workloads; analytical (OLAP) queries have different optimization priorities.