Resource
Execution Plan Analysis — Read What the Engine Actually Chose
Optimize what the engine does, not what the SQL looks like: cost concentration, estimate-vs-actual gaps, and plan warnings — with forensic evidence rules.
Coding Workflows
SQL Optimization Prompt
"Optimize this query" gets generic indexing advice. Pick a goal, a database platform, and an evidence mode — and get an optimization contract: execution-plan thinking, per-platform guidance, justified index recommendations with their write tax, and a forensic mode where generic advice is forbidden and missing evidence becomes a command to gather it.
Which query, slow in what way? E.g. "Find why the order-search query behind GET /orders takes four seconds."
Evidence Mode
Forensic is the flagship: every conclusion cites evidence, and generic advice is forbidden.
How slow, since when, for which inputs — measured, not felt.
Paste it and the prompt carries it verbatim — the detector also flags SELECT * and non-sargable patterns.
If you have it, the analysis grounds in it. If not, the prompt demands the capture command instead of inventing one.
Optimization Preview (live — the contract's shape, not the output)
SQL Optimization Prompt
Resource
Missing Index Analysis — Which Indexes, at What Cost
Map every predicate, join, and sort to the index that serves it — or doesn't. Composite order rules, covering decisions, and the write tax nobody mentions.
Resource
MySQL Query Optimization — InnoDB Realities, type=ALL
EXPLAIN shows type=ALL on a 1.2M-row table: full scan on every search. MySQL optimization with InnoDB clustering realities, version-aware optimizer limits, and covering reads.
Resource
Optimize Reporting Queries — Read Millions, Return Rows
An 11-minute report that reads two years of orders to return 24 rows: the rows-read to rows-returned ratio is the target — filters pushed down, pre-aggregation costed honestly.
Resource
Optimize SQL Query — Joins, Cardinality, and Wasted Work
A five-table join that got slow as data grew: establish cardinality first, check each join strategy against the data shape, and hunt the fan-out doing wasted work.
Resource
PostgreSQL Query Analysis — EXPLAIN (ANALYZE, BUFFERS) Reading
A real plan with the story inside: estimate says 42 rows, actual is 51,840. PostgreSQL analysis grounded in the plan — stale statistics, bloat, planner costs, and the index arsenal.
Resource
Slow Query Investigation — Degrading Month Over Month
Queries that were instant at launch and crawl a year later: scale-aware investigation of work that grows faster than the data, before it owns the server.
Resource
SQL Optimization Prompt — the Evidence-Based Contract
"Optimize this query" gets generic indexing advice. The optimization contract demands evidence: real bottlenecks, justified indexes with their write tax, and no invented plans.
Resource
SQL Performance Analysis — Surviving the Billion-Row Table
At 240M rows and growing: keyset pagination over OFFSET, partition pruning, and the PostgreSQL specifics — analysis aimed at the scale the table will reach, not the scale it passed.
Resource
SQL Server Query Tuning — Plans, Sniffing, Clustering Keys
Fast for most customers, 30x slower for the largest two — the parameter sniffing signature. SQL Server tuning with actual plans, clustering-key economics, and CONVERT_IMPLICIT hunting.
Workflow
AI Database Design Workflow
Design a schema on its data, not a hunch — model the entities and relationships, set the constraints that protect integrity, plan indexes around real queries, then document the schema and migration.
Project
Build a SaaS MVP with AI
The full path from idea to a shipped SaaS MVP — define and scope the requirements, design the architecture, API, and data model, then build it reviewed, tested, secured, cost-controlled, and deployed.
Project
Build an API Backend with AI
The full path to a backend you can put clients on — define the requirements, design the architecture, API contract, data model, and access control, then build it reviewed, tested, secured, and shipped.
Project
Build an Applicant Tracking System with AI
The full path to an applicant tracking system — model jobs, candidates, and hiring stages, generate job descriptions and screening prompts, parse résumés into structured data, design the hiring API, set roles, review security, then ship.
Project
Build a Booking System with AI
The full path to a booking and reservation system — model resources, availability, and reservations, design the booking API, set customer accounts, wire calendar and notification integrations, design the UI, review security, then ship.
Project
Build an Inventory Management System with AI
The full path to an inventory management system — model products, stock, locations, and movements, design the inventory API, set roles, plan supplier and POS integrations, design the UI, review data-integrity risks, then ship.
Project
Build an Internal Admin Panel with AI
The full path to an internal admin panel — model the operational data it manages, design the management API, define RBAC and admin permissions, design the tables and forms, review risky admin actions, then ship to trusted internal users.
Project
Build a Marketplace with AI
The full path to a two-sided platform — define the buyer-and-seller requirements, model the data, design the API, build roles and permissions, wire integrations, design the UI, then test, secure, and ship it.
Project
Build a CRM with AI
The full path to a CRM that fits your sales process — define the contacts, deals, and pipeline, model the data that ties them together, then build the roles, integrations, and pipeline UI, and ship.
Project
Build an E-commerce Store with AI
The full path to a store you own end to end — model the catalog and orders, design the storefront and checkout, add customer accounts and payments, then secure it, test it, and ship.
Project
Build a Data Pipeline with AI
The full path to a pipeline that moves data without corrupting it — design the ingestion and transforms, extract and structure the sources, gate the quality, store it, then deliver and ship it monitored.
How it works
State the optimization objective, pick the goal — Query Speed, Join Optimization, Index Strategy, Large Dataset Scaling, Reporting Query Optimization, or Execution Plan Analysis — and choose the database platform and evidence mode. Each goal is a different optimization philosophy with its own priorities and analysis areas; each platform adds real engine-specific guidance — actual-plan tooling, optimizer quirks, clustered-index realities — not just a label. Then provide what evidence you have: the query (the detector flags SELECT * and non-sargable patterns), the execution plan, tables with row counts, existing indexes, and measured symptoms. What you can't provide changes the contract: no plan means the prompt demands the exact capture command instead of inventing one; no index list means no index may be assumed. Click Generate SQL Optimization Prompt for the full contract — bottleneck analysis, impact-ordered opportunities, justified index recommendations with their write tax, tradeoffs, and an assumptions ledger. Forensic mode adds the rule that defines the tool: generic advice is forbidden. Nothing leaves your browser.
Best for
- Tuning a slow query with evidence — plan, schema, and platform
- Optimizations grounded in what the database actually does, not guesses
- Engine-specific tuning for Postgres, MySQL, and others
Not for
- Reviewing application code in general — that is the Code Review Prompt Generator
- Designing a schema from scratch rather than tuning queries
Use cases
- Turning "optimize this query" into an evidence-based analysis contract
- Reading an EXPLAIN ANALYZE output operator by operator
- Getting index recommendations that name their clause and their write tax
- Making queries survive growth instead of just passing today
Pro tips
- Paste the actual execution plan if you possibly can — it is the single most valuable input. Estimate-vs-actual row gaps in a real plan settle arguments that query text alone never will.
- Use Forensic mode when you're tired of generic advice: its rule that "a recommendation that would read the same without ever seeing this query does not belong in the analysis" changes what the model dares to say.
- Fill in row counts even roughly (12M, 900K, 40). Join strategy and index advice without cardinality is guesswork — and the contract will say so instead of guessing.
- Take the verification step seriously: every recommendation comes with how to measure it — plan and timing before and after, on production-shaped data. An optimization that was never measured is a hypothesis.
FAQ
Does this tool optimize my query?
No — it builds the contract. The output is a prompt that instructs an AI how to analyze and optimize your SQL: which philosophy to apply, what platform realities to respect, what evidence to demand, and how to justify every recommendation. The flagship is the evidence discipline — no invented execution plans, no assumed indexes, no assumed row counts, and in Forensic mode, no generic advice at all.
Why is "optimize this query" a weak prompt?
Because it gets generic database advice: "add an index on the WHERE columns, avoid SELECT *" — recommendations that read the same for every query ever written. Real optimization is evidence work: which operator concentrates the cost, what the estimate-vs-actual gap says about statistics, whether the join order matches the cardinalities, what each candidate index taxes on writes. The contract demands exactly that, and forbids the rest.
Why is the database platform a mode and not separate tools?
Same reasoning as frameworks in the Test Case Prompt Generator: the optimization question is identical — only the engine realities differ. SQL Server brings parameter sniffing and clustering-key economics; PostgreSQL brings EXPLAIN (ANALYZE, BUFFERS), bloat, and planner cost settings; MySQL brings InnoDB realities and version-specific optimizer limits. Each platform mode injects that real guidance into the same contract — and the platform-specific search intents live as resources.
My app is slow — should I use this or the Debugging Prompt Generator?
Depends on what you know. If you don't yet know where the time goes — could be code, could be network, could be the database — start with the Debugging Prompt Generator's performance investigation: it finds the bottleneck. Once the suspect is a specific query, this tool takes over: query-level analysis is its entire job. In this category's verbs: Debugging investigates, SQL Optimization optimizes.
What happens if I don't have the execution plan?
The contract refuses to fake one. Its non-goals open with "do not invent execution plans" — so instead, the prompt demands the exact capture command for your platform (EXPLAIN (ANALYZE, BUFFERS) on PostgreSQL, the Actual Execution Plan plus SET STATISTICS IO, TIME ON on SQL Server) and marks every plan-dependent conclusion as pending that evidence. In Forensic mode, gathering the missing evidence becomes the first recommendation itself.
How is this different from the Code Review Prompt Generator's SQL option?
Review's SQL language mode judges code that happens to contain SQL — injection risks, readability, obvious anti-patterns — from a reviewer's perspective. This tool owns performance: execution plans, cardinality, join strategy, index economics. The category rule is strict: everything SQL-performance belongs here, which is why the review tool deliberately has no database-review resources.
Will it recommend indexes?
Only with a pedigree. The contract's index rules: every recommendation must name the exact predicates, joins, or sorts it serves — no index without a clause; composite column order must be justified; covering decisions come with their storage and write cost; and every index states its write tax — which inserts and updates it slows. It also checks existing indexes first: extending a near-miss index beats creating an overlapping new one.