Performance work is satisfying because it's measurable — you either made it faster or you didn't. But knowing where to look is half the battle. These skills cover profiling, caching strategies, database indexing, ORM query optimization, and the data layer decisions that determine whether your app stays responsive at scale or falls over at the first traffic spike.
Key takeaway
ClaudeVault's performance and data skills give Claude Code structured workflows for the places most apps actually get slow — unindexed queries, N+1 ORM patterns, cache invalidation, and hot code paths. They cover Postgres EXPLAIN plans with hypopg index simulation, Prisma and Drizzle eager-loading strategies, Redis cache-aside and write-through patterns, and the profiling loops that let Claude explain why code is slow instead of just where.
When a single endpoint owns 80% of the latency budget and nobody knows which query is the culprit
When an ORM migration surfaced dozens of N+1 queries that only show up under production traffic
When Redis cache hit rates are dropping and invalidation events are not well-defined
When a database bill is growing faster than traffic and the team suspects the indexes are wrong
A full Claude Code performance pass chains these four skills so Claude measures before it guesses and indexes before it caches.
Start with the performance profiler. Claude reads runtime traces, flame graphs, and hot paths to identify the specific endpoints and functions worth touching. Skipping this step is how teams end up optimizing a 5ms function while a 400ms query runs three times per request.
Hand the hot queries to the database index advisor. Claude runs EXPLAIN ANALYZE with BUFFERS, simulates candidate indexes with hypopg, and recommends composite or partial indexes that actually get picked by the planner — not ones that sit on disk unused.
Use the ORM query advisor to rewrite N+1 hotspots with Prisma include/select, Drizzle relationLoadStrategy, or DataLoader batching. Claude keeps the call sites identical so the fix does not leak into the rest of the codebase, and adds a regression test that counts query executions.
Finally, the caching strategy designer picks cache-aside, write-through, or TTL-based patterns per endpoint, with named invalidation events so the team has something to argue about when stale data appears in production. Redis TTL on its own is a timer, not a cache strategy.
Outcome
Slower endpoints measured, unindexed queries fixed, N+1 patterns collapsed, and a cache layer with written invalidation rules the team can reason about under incident pressure.
| Skill | Best for | Complexity | Primary use case |
|---|---|---|---|
| Performance Profiler | Endpoints with mystery latency | Advanced | Hot path and flame graph analysis |
| Database Index Advisor | Query plans missing composite indexes | Advanced | EXPLAIN ANALYZE with hypopg simulation |
| ORM Query Advisor | Prisma and Drizzle codebases with N+1 patterns | Intermediate | Eager loading, DataLoader, and batch queries |
| Caching Strategy Designer | Read-heavy endpoints needing Redis or edge cache | Intermediate | Cache-aside, write-through, and invalidation events |
Identifies performance bottlenecks and proposes targeted optimizations with measurable impact. Use when code, queries, or endpoints are running slower than expected. Profiling, algorithmic complexity, I/O bottlenecks.
Focuses on the changes that matter most, not micro-optimizations.
Reads ORM code and identifies the SQL it generates, spotting N+1 queries, over-fetching, and missing eager loads. Use when reviewing ORM queries for performance or when endpoints are unexpectedly slow. Prisma, Drizzle, TypeORM, SQLAlchemy, ActiveRecord.
Translates ORM code into the SQL it produces, spots the problems, and fixes them in ORM terms — without dropping to raw queries unless necessary.
Analyzes queries, schemas, and access patterns to recommend indexes that eliminate full table scans. Use when queries are slow, designing a new schema, or reviewing EXPLAIN plans. Indexing, query optimization, N+1 detection, ESR rule.
Recommends indexes based on actual query patterns and data distribution.
Designs multi-layer caching architectures with explicit invalidation strategies. Use when adding caching layers, diagnosing stale data bugs, or choosing between in-memory, Redis, and CDN caching. Cache invalidation, TTL design, thundering herd, write-through.
Every caching decision starts with "what happens when this data changes?" If you cannot answer that clearly, do not cache it.
Yes. The ORM query advisor reads models, routes, and service code together, spots DB calls inside loops, and rewrites them with Prisma include/select or Drizzle relationLoadStrategy. Claude adds a regression test asserting the expected query count so the pattern cannot silently return after a later refactor.
Yes, especially with the Postgres MCP Pro server. Claude Code can run EXPLAIN ANALYZE with BUFFERS, simulate candidate indexes via hypopg, and reason about whether a new composite index would actually get picked by the planner instead of sitting on disk unused.
The caching strategy designer picks cache-aside, write-through, or TTL-based patterns per endpoint and writes down the named invalidation events that should bust each cache entry. Claude refuses to ship 'just set a TTL and hope' because a TTL on its own is a timer, not a strategy.
Claude Code does not ship its own profiler, but it reads output from Node, Python, and Go profilers and explains why code is slow instead of just where. For precise runtime measurement you still need a native profiler — Claude's value is the reasoning layer on top of the numbers.
Yes. Given a slow query and its plan, Claude rewrites it to reduce SELECT * fan-out, push filters closer to the data, and use composite indexes that match the WHERE and ORDER BY columns in the right prefix order. Claude cites the plan cost delta, not just a code diff.
Hypopg is a Postgres extension that simulates indexes without actually creating them, so Claude can test whether a candidate index would be picked by the planner before spending minutes building it on a large table. It is the difference between index guessing and index design.