Database Optimization
Improve database performance and migration safety using measured workload evidence, query-plan analysis, schema and index review, and reversible change planning.
A focused method your agent applies to a specific problem or piece of work.
Ask your connected agent for an outcome. It finds relevant methods and business context.
- What you get
- What to bring
- database engine and current version
- schema and migration history
- representative workload and critical queries
- observed latency, throughput, resource, lock, or saturation evidence
- query plans or database-native diagnostics when available
- application data-access patterns
- data volume and growth evidence
- consistency, durability, retention, and privacy constraints
- deployment and rollback constraints
How it works 3 steps
A typical way this skill turns context into a useful result. The exact choices depend on your task.
- 01
Frame the task Input Your goal and relevant context→Output A focused starting point
- 02
Apply the skill Input The focused starting point→Output A draft or recommendation
- 03
Review and refine Input The draft or recommendation→Output A result ready to use
↶ Review, learn, and revisit an earlier step when needed.
Decision rules
- Do not add an index without a demonstrated access pattern or integrity requirement it supports. - Do not assume a sequential scan, join type, cache miss, or other plan operator is inherently wrong; interpret it in workload context. - Do not replace application queries with larger joins or aggregations unless the resulting plan, data shape, and memory/network behavior are actually better. - Do not denormalize without a clear read/write tradeoff and ownership plan. - Do not tune connection pools from generic formulas alone; use database, application, and infrastructure limits plus observed concurrency. - Prefer measured query and schema changes over speculative infrastructure scaling. - Avoid production changes whose lock, rewrite, replication, or rollback behavior has not been understood for the current engine/version. - Reversible migration is preferred, but some database changes are not cleanly reversible; when rollback is unsafe, define a forward-recovery plan explicitly. - Optimization is successful only when the target workload improves without unacceptable regression elsewhere.
Guardrails
- Do not add an index without a demonstrated access pattern or integrity requirement it supports. - Do not assume a sequential scan, join type, cache miss, or other plan operator is inherently wrong; interpret it in workload context. - Do not replace application queries with larger joins or aggregations unless the resulting plan, data shape, and memory/network behavior are actually better. - Do not denormalize without a clear read/write tradeoff and ownership plan. - Do not tune connection pools from generic formulas alone; use database, application, and infrastructure limits plus observed concurrency. - Prefer measured query and schema changes over speculative infrastructure scaling. - Avoid production changes whose lock, rewrite, replication, or rollback behavior has not been understood for the current engine/version. - Reversible migration is preferred, but some database changes are not cleanly reversible; when rollback is unsafe, define a forward-recovery plan explicitly. - Optimization is successful only when the target workload improves without unacceptable regression elsewhere.
Example outcome request
Describe the result you need and add your team's context. Your connected agent finds the methods that fit.
I want this outcome: Improve database performance and migration safety using measured workload evidence, query-plan analysis, schema and index review, and reversible change planning.
Use my team's shared skills, workflows, and business context through Popasoda to find the relevant methods. Consider Database Optimization (database-optimization) if it fits the goal. Ask for missing context before starting, and follow the chosen methods' review gates and guardrails.
Relevant guardrails for this method: - Do not add an index without a demonstrated access pattern or integrity requirement it supports. - Do not assume a sequential scan, join type, cache miss, or other plan operator is inherently wrong; interpret it in workload context. - Do not replace application queries with larger joins or aggregations unless the resulting plan, data shape, and memory/network behavior are actually better. - Do not denormalize without a clear read/write tradeoff and ownership plan. - Do not tune connection pools from generic formulas alone; use database, application, and infrastructure limits plus observed concurrency. - Prefer measured query and schema changes over speculative infrastructure scaling. - Avoid production changes whose lock, rewrite, replication, or rollback behavior has not been understood for the current engine/version. - Reversible migration is preferred, but some database changes are not cleanly reversible; when rollback is unsafe, define a forward-recovery plan explicitly. - Optimization is successful only when the target workload improves without unacceptable regression elsewhere.