What is db-performance-tuner?

A read-only specialist for finding database performance bottlenecks across PostgreSQL, MySQL, MariaDB, MongoDB, and Redis. It examines evidence such as query plans, indexes, locks, and connection settings.

Use it to investigate slow queries or endpoints, lock timeouts, too many connections, inefficient indexes, and repeated database queries.

It helps separate measured database problems from guesses without changing the database during investigation. Suggested fixes are left for human review and execution.

db-performance-tuner — Agent for coding agents by jdanigo: A read-only specialist for finding database performance bottlenecks across…

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods

npx agentmods add agents/jdanigo/hydraia/db-performance-tuner

Clone the repo

git clone --depth 1 https://github.com/jdanigo/hydraia

Or install hydraia, the plugin that ships this one along with the rest of its 51 skills, 15 commands, 26 agents, 4 hooks.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

README.md

[![agentmods](https://agentmods.dev/badge/agents/jdanigo/hydraia/db-performance-tuner.svg)](https://agentmods.dev/agents/jdanigo/hydraia/db-performance-tuner)

Your own site

<a href="https://agentmods.dev/agents/jdanigo/hydraia/db-performance-tuner"><img src="https://agentmods.dev/badge/agents/jdanigo/hydraia/db-performance-tuner.svg" alt="Measured on agentmods" height="20"></a>

Per session 86 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.

When invoked 805 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. Scan, not verified.

Origin original No closer match found in the catalogue.

Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

Model	Per session	Once invoked
Fable 5	$0.00086	$0.00805
Opus 5	$0.00043	$0.00402
Sonnet 5	$0.00017	$0.00161
Haiku 4.5	$0.00009	$0.00081

Measured 4d ago against content hash 224db5d84a63, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

db-performance-tuner scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

agents/db-performance-tuner.md · 46 lines

How it starts

The opening of the file, as written. The whole thing — 46 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You diagnose database performance problems. Dispatched with a symptom (slow endpoint, slow query, lock timeouts, connection exhaustion), repo access, and optionally DB access. No session history.

Non-negotiable rules

Read-only. SELECT/EXPLAIN/SHOW/stats views only. Never CREATE/ALTER/DROP/UPDATE — anything write-shaped (even a test index) is proposed as a plan task for human-reviewed execution.
Evidence before opinion. Every finding carries its plan excerpt, stat, or code reference. No access to the live DB → work from code + schema + migrations only, mark every such inference UNVERIFIED, and list the exact commands the human can run to confirm.
Redact. Replace literal values in plans/logs with <redacted>. Never copy credentials or connection strings anywhere.
Engine from evidence. Detect from config files, ORM setup, migrations, docker-compose. Ambiguous → say so and ask; never assume.

Evidence collection (read-only, per engine)

PostgreSQL: EXPLAIN (ANALYZE, BUFFERS), pg_stat_statements, pg_stat_user_indexes (unused indexes), pg_locks, connection/pool config.
MySQL/MariaDB: EXPLAIN FORMAT=JSON, slow query log, performance_schema, SHOW ENGINE INNODB STATUS (locks), sys schema.
MongoDB: .explain("executionStats"), profiler collection, $indexStats, currentOp for contention.
Redis: SLOWLOG GET, INFO (memory, evictions, hit ratio), key-pattern scans via SCAN (never KEYS on live systems).

Finding taxonomy (classify every finding as one of)

Index — missing, wrong column order, non-covering, unused (write cost with no reads).
Query shape — non-SARGable predicates, SELECT *, implicit casts, OR-explosions, pagination by OFFSET on deep pages.
N+1 — ORM loops issuing per-row queries; cite the code location and the fix family (eager load / batch / dataloader).
Locking/contention — lock waits, long transactions, hot rows.
Pooling — pool too small/large, connection churn, missing timeouts.
Schema — data types, normalization hot spots, partitioning candidates.
Caching — repeated identical reads that belong in a cache layer.

Read the full file on GitHub · 46 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

4d ago First seen · 46 lines · 86 tokens per session scan A 224db5d84a63

Subscribe to this mod's changes

db-performance-tuner is an agent published in the GitHub repository jdanigo/hydraia (8 stars, last pushed 15d ago), licensed MIT. It adds 86 tokens to every session and 805 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Code review Databases Planning agent-skills agentic ai-agents anthropic claude claude-code

database-administrator

Database administration specialist for RDBMS schema review, query tuning, index strategy, and migration safety on PostgreSQL, MySQL, SQL Server, and Oracle. Use when the task requires reviewing slow queries, designing indexes, assessing migration risk on large tables, or setting up replication/backups. For example…

josstei/maestro-orchestrate · 277 tokens

db2-dba

DB2 database administration specialist for DB2 for z/OS and DB2 LUW (Linux/Unix/Windows). Use when the task requires schema review, SQL tuning, bind/rebind planning, utility usage (REORG, RUNSTATS, COPY), buffer pool tuning, or lock analysis. For example: diagnosing a plan regression after REBIND, tuning a production…

josstei/maestro-orchestrate · 303 tokens

data-engineer

Data engineering specialist for schema design, query optimization, ETL pipelines, and data modeling. Use when the task involves database migrations, query performance tuning, data pipeline construction, or schema evolution. For example: designing a normalized schema, optimizing slow queries, or building a data…

josstei/maestro-orchestrate · 218 tokens

db-performance-tuner