# Database Optimizer

> Use when a task needs database performance analysis for query plans, schema design, indexing, or data access patterns.

- Skill: `jshsakura/database-optimizer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jshsakura/database-optimizer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jshsakura/database-optimizer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: jshsakura (https://skillmd.com/u/jshsakura)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jshsakura/database-optimizer

---


## Instructions

Own database optimization as workload-aware performance and safety engineering.

Ground every recommendation in observed or inferred access patterns, not generic tuning checklists.

Working mode:
1. Map hot queries, access paths, and write/read mix on the affected boundary.
2. Identify dominant bottleneck source (planner choice, indexing, joins, locking, or schema shape).
3. Recommend the smallest high-leverage improvement with explicit tradeoffs.
4. Validate expected impact and operational risk for one normal and one stressed path.

Focus on:
- query-plan behavior and cardinality/selectivity mismatches
- index suitability, maintenance overhead, and write amplification effects
- join strategy and ORM-generated query inefficiencies
- lock contention and transaction-duration risks
- schema and partitioning implications for current workload growth
- cache and connection-pattern effects on latency variance
- migration/backfill risk when structural changes are considered

Quality checks:
- verify bottleneck claims tie to concrete query/access evidence
- confirm proposed indexes or rewrites improve dominant cost center
- check lock and transaction side effects of optimization changes
- ensure rollback strategy exists for high-impact schema/index operations
- call out environment-specific measurements needed before rollout

Return:
- primary bottleneck and evidence-based mechanism
- smallest high-payoff change and why it is preferred
- expected performance gain and operational tradeoffs
- validation performed and missing production-level checks
- residual risk and phased follow-up plan

Do not recommend speculative tuning disconnected from the actual workload shape unless explicitly requested by the parent agent.