Hire an AI database performance analyst
Give it your database engine and version, such as PostgreSQL 15 or MySQL 8. You get findings ranked by impact, each tied to evidence in your query plan.
What you give
- Your database engine and version, such as PostgreSQL 15 or MySQL 8
- The slow queries, with the output of EXPLAIN ANALYZE for each
- Rough row counts for the biggest tables
What you get
- Findings ranked by impact, each tied to evidence in your query plan
- Exact index and query changes, with the reason for each
- A safe way to apply each change on a live database, and a way to undo it
- A list of checks to run on a copy of your data, with the numbers to compare
An example
A page or report is slow and you suspect the database.
You ask: “Give it your database engine and version, such as PostgreSQL 15 or MySQL 8. Use the material I attach and ask for anything essential that is missing.”
You get back:
- Setup and evidence used. Your engine and version, the plans it read and any evidence still missing.
- Findings. Problems ranked by impact, each with the line in the plan that shows it and the fix.
- Proposed changes. The exact index or query change for each finding, with the reason and its cost.
An example, not your task.
Hire this specialist
It is free and needs no account. Download the pack, give it to your AI and tell it the job. Your AI asks for anything it is missing, then does the work and checks it.
Related specialists
Details
Everything it can hand back
Your task sets the actual outputs. The specialist picks the methods that cover them.
- Findings ranked by impact, each tied to evidence in your query plan.
- Exact index and query changes, with the reason for each.
- Fixes for repeated one-per-row queries, shown as one combined query.
- A safe way to apply each change on a live database, and a way to undo it.
- A list of checks to run on a copy of your data, with the numbers to compare.
- Notes on connection pooling and slow-query monitoring.
How it does the job well
- Give no speed-up figure. Say the user must measure before and after on a copy of their data.
- Do not run or approve changes on a live database. Give the change with an undo step and let the user apply it.
- Product behaviour differs by engine and version. Say to check the database's own documentation for the user's version.
- Always Check Query Plans: Run EXPLAIN ANALYZE before deploying queries
- Index Foreign Keys: Every foreign key needs an index for joins
- Avoid SELECT *: Fetch only columns you need
- Use Connection Pooling: Never open connections per request
Mistakes it avoids
- Claiming code works without running it or its tests.
- Inventing APIs, package versions or settings instead of checking the installed ones.
- Changing behaviour outside the request, such as reformatting whole files or renaming public interfaces.
What a good result looks like
An example, not your task: A page or report is slow and you suspect the database.
- Setup and evidence used. Your engine and version, the plans it read and any evidence still missing.
- Findings. Problems ranked by impact, each with the line in the plan that shows it and the fix.
- Proposed changes. The exact index or query change for each finding, with the reason and its cost.
- Apply and undo. A safe way to apply each change on a live database and the step to undo it.
- Checks on a copy. The queries to rerun, what to measure before and after and the rule for a pass.
- Connections and monitoring. Pooling notes and slow-query logging, with what to watch after the change.
How the work is checked
- The changed files build, and the relevant tests and linters pass. The commands and results are shown.
- Each change is explained in one line with its reason, and risky areas are named.
- Any check that could not run is reported as NOT_RUN with what it needs.
- States which checks passed, failed or could not run, and names missing inputs.
These checks have not been run against a model yet. Your AI uses them to check its own work.
A second opinion
Before it hands back, your AI reviews the draft the way John Carmack would. This is a way of reviewing the work. It does not mean they wrote or endorse it.
Capabilities
- Read the plans. It reads each plan for full table scans, estimates that miss, slow joins and sorts that spill to disk.
- Find repeated queries. It spots the pattern where the app runs one query per row, and replaces it with one combined query.
- Check the indexes. It checks that joins have indexes and that filters match them. It considers partial and combined indexes where they fit.
- Review the schema. It checks table design, data types and constraints, and weighs clean structure against speed.
- Write safe changes. Each change is reversible. Indexes on live PostgreSQL tables use the option that avoids locking the table.
- Plan connections and monitoring. It checks that the app reuses connections, and that slow queries are logged, for example with pg_stat_statements.
- Plan the test. It lists what to run on a copy and which numbers to compare before and after.
How the role works
- Checks your task, context and available tools.
- Picks the methods needed and prepares a work plan.
- Carries out supported tasks, with each method's limits and review gates.
- Checks the real deliverables and corrects supported faults.
- Hands back files, evidence and unresolved gaps.
Your specialist's working setup
Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.
Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.
Use this specialist through MCP or the API
Call prepare_specialist with role_id engineering-database-optimizer only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.
For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.
Complete ZIP: Download base specialist. API: GET /api/v1/specialists/engineering-database-optimizer/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.
Inputs and helpful context
The specialist starts from the task brief. Only active methods require their inputs.
For the primary method, when used
- Your database engine and version, such as PostgreSQL 15 or MySQL 8.
- The slow queries, with the output of EXPLAIN ANALYZE for each.
- Your table definitions and existing indexes.
- Rough row counts for the biggest tables.
- How the app calls the database, such as an ORM or raw SQL (optional).
- Which queries matter most to your users (optional).
Helpful context (optional)
- The slow query log from your database.
- Your ORM or app code for the slow page.
- Table sizes from your database's own statistics.
Tools and access
- Claude, ChatGPT or Gemini: Any of them can read plans and schemas you paste. Give the full plan, not a summary.
- A staging copy of your database: It lets you test each change and compare plans before you touch the live data.
Functions and deliverables
- Database performance analyst: Get a ranked list of slow database queries, missing indexes and risky schema choices, with safe fixes you can test on a copy first.
- Findings ranked by impact, each tied to evidence in your query plan.
- Exact index and query changes, with the reason for each.
- Fixes for repeated one-per-row queries, shown as one combined query.
- A safe way to apply each change on a live database, and a way to undo it.
- A list of checks to run on a copy of your data, with the numbers to compare.
- Notes on connection pooling and slow-query monitoring.
- Database schema planner: Share SQL table definitions. Get a schema review, query and index advice, and a migration plan.
- Schema issues list
- Table diagram
- Index recommendations
- Step by step migration plan
- Database designer: Describe your app. Get a database and ORM pick with reasons, a schema outline, an index plan and safe steps to change it later.
- A database pick with the reasons for it
- An ORM pick with the trade-offs
- A schema outline with keys and links between tables
- An index plan
- Safe steps for changing the schema later
- Slow query fixer: Share a slow SQL query and plan. Get likely causes, query or index changes, and checks for speed and identical results.
- The cause of the slowdown
- A rewritten query
- Index statements to add
- A before and after plan comparison
- AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
- A ready rules file for your project
- A list of which files to load for each task
- Rules for when to reset or trim the session
- A checklist for spotting drifting answers
- John Carmack: Find a bug, slow step or excess scope through John Carmack’s recorded approach. Follow the actual run, measure first and expose hidden state.
- Your problem worked on the way John Carmack would: their questions, their method, their push-back
- The answer or the work, in John Carmack's voice, using their ideas by name
- Anything that goes beyond their public record, marked
- One suggested next step
Tasks you can use it for
- A page or report is slow and you suspect the database.
- Your app makes one query per row in a loop, and the list page crawls.
- You are about to add an index or change a table on a live database and want it checked first.
- You are designing tables for a new feature and want indexes planned from the start.
Limits to check before starting
- You have one slow query and want it rewritten. Use the Slow query fixer.
- You want queries written from plain words. Use the Plain-words SQL writer.
- Your concern is backups, failover or uptime. Use the Database recovery planner.
- You run GaussDB. Use the GaussDB query and schema reviewer.
- You plan to run changes on a live database with no copy to test on. Ask a database administrator.
Best way to use this role
Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.
- Download the pack from this page and add it to your AI as a skill. Or paste SKILL.md into a new chat, then paste references/source-agent.md after it.
- Run EXPLAIN ANALYZE on each slow query and copy the whole output. For a query that writes data, run it in a transaction and roll back, or ask the agent for plain EXPLAIN steps.
- Paste the queries, plans, table definitions, indexes and row counts. Name your engine and version.
- Your AI asks once for anything missing. Without a plan it gives only general advice and says so.
- Try each fix on a copy of your database. Run EXPLAIN ANALYZE again and compare with the first output.
- Apply changes to the live database yourself, one at a time, in a quiet period, using the undo step if needed.
Read it as data
Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/engineering-database-optimizer for its role instructions and pinned sources.
This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.