SQL is still the most important language in data work, and writing correct SQL is only half the job. Writing SQL that performs well on real datasets, that's readable by the next person, and that doesn't silently produce wrong results — that's the other half. These skills cover query writing, performance tuning, optimization, and the practical SQL work that data teams do every day.
Key takeaway
ClaudeVault's SQL and query skills give Claude Code structured workflows for the three SQL disciplines that separate correct queries from fast, maintainable ones — query writing with CTEs, window functions, and dialect-aware syntax for PostgreSQL, MySQL, BigQuery, and Snowflake, performance tuning using EXPLAIN ANALYZE output to identify bottlenecks, and query optimization that restructures slow queries without changing their results. Claude Code connects directly to databases via DBHub MCP for schema-aware SQL generation from the terminal.
When a dashboard query takes 45 seconds to load and nobody has looked at the execution plan to understand why
When analysts copy-paste SQL from Slack because writing correct joins across six normalized tables is error-prone without schema documentation
When query performance degrades as data volume grows and the fix has been adding more warehouse compute instead of optimizing the query itself
A Claude Code SQL workflow starts with writing correct queries, then tunes them for performance using execution plan analysis, and finally restructures complex queries for long-term maintainability.
Start with the SQL writer. Claude generates queries with CTEs for readability, window functions where aggregation spans rows, and dialect-specific syntax for your target database — PostgreSQL array operations, BigQuery UNNEST patterns, Snowflake FLATTEN. With DBHub MCP connected, Claude reads the live schema so every table and column reference is validated against reality.
The SQL performance tuner reads EXPLAIN ANALYZE output and identifies the specific bottleneck — sequential scans that should be index scans, hash joins that spill to disk, subqueries that execute per-row instead of once. Claude translates execution plan nodes into plain language and recommends the index, join rewrite, or materialization that fixes the actual bottleneck.
Finally, the query optimizer restructures complex queries without changing their results. Claude replaces correlated subqueries with joins, materializes expensive CTEs used multiple times, rewrites OR chains as UNION ALL when the optimizer cannot merge them, and adds partition pruning hints for large time-series tables.
Outcome
Correct SQL generated with schema awareness and dialect-specific syntax, performance bottlenecks identified from execution plans, and complex queries restructured for both speed and readability — three skills that cover the full SQL lifecycle from writing to production tuning.
| Skill | Best for | Complexity | Primary use case |
|---|---|---|---|
| SQL Writer | Query generation and dialect-aware syntax | Beginner | CTEs, window functions, and joins with schema validation via MCP |
| SQL Performance Tuner | Execution plan analysis and index recommendations | Advanced | EXPLAIN ANALYZE interpretation with specific bottleneck diagnosis |
| Query Optimizer | Complex query restructuring | Advanced | Subquery elimination, materialization, and partition pruning for large datasets |
Diagnoses slow SQL queries through execution plan analysis with targeted index, rewrite, and configuration fixes. Use when a specific query runs too slowly and you have the execution plan. EXPLAIN ANALYZE interpretation, index strategy, query rewriting.
Diagnose why a specific SQL query is slow by reading its execution plan, identifying the highest-cost operations, and prescribing targeted fixes — indexes, rewrites, or configuration changes — with es
Translates natural language data requests into correct, optimized SQL with proper joins, aggregation, and injection prevention. Use when you need a query written from a plain-English description. Dialect-aware, parameterized, safe queries.
Translate natural language data requests into correct, optimized, safe SQL — with proper joins, filtering, aggregation, and parameterized placeholders for application code.
Analyzes slow SQL queries through execution plans and recommends indexing, rewrites, and configuration changes. Use when SQL queries run too slowly. EXPLAIN analysis, index strategy, query rewriting, materialized views.
Analyze slow queries, interpret execution plans, identify bottlenecks, and recommend specific optimizations — rewrites, indexes, schema changes, or configuration adjustments — with estimated impact.
Yes. The SQL writer generates queries with CTEs, window functions, and dialect-specific syntax for PostgreSQL, MySQL, BigQuery, Snowflake, and SQL Server. Claude Code connects to databases via DBHub MCP, which means it reads the live schema and validates every table and column reference — producing queries that are not just syntactically valid but semantically correct.
The SQL performance tuner translates execution plan nodes into plain language. It identifies the specific bottleneck — a sequential scan that needs an index, a hash join spilling to disk, a nested loop executing per-row — and recommends the fix. Most slow queries have one or two root causes, not a dozen, and the execution plan pinpoints them.
CTEs are almost always more readable and maintainable. Performance is database-dependent: PostgreSQL materializes CTEs by default before version 12, which can hurt performance if the CTE result is large. BigQuery and Snowflake inline CTEs automatically. The SQL writer generates the appropriate pattern for your dialect.
Through DBHub MCP — a Model Context Protocol server that connects to PostgreSQL, MySQL, SQL Server, and SQLite. Once connected, Claude Code can inspect schemas, list tables and columns, and generate SQL that references real table structures instead of guessing. The connection uses read-only access by default for safety.
Three techniques cover most performance improvements: adding indexes on columns used in WHERE and JOIN clauses, replacing correlated subqueries with joins or lateral joins, and adding partition pruning conditions for time-series tables. The query optimizer identifies which of these applies to your specific slow query using the execution plan.