Executive summary
The affected workflow, current symptom, likely database pressure, impact estimate, confidence level, and recommended review order.
Sample report
A database optimization report should show evidence before recommendations.
Use this broad sample report model to understand what an audit should return: visible symptoms, database evidence, ranked findings, review notes, timing, and safety boundaries. It does not promise automatic fixes for every database engine.
Report sections
What the report should include
The useful output is a short decision document, not a pile of raw database metrics.
Evidence inventory
Representative queries, execution plans, index lists, table sizes, wait notes, growth signals, hosting limits, and maintenance context.
Prioritized findings
Findings ranked by user impact, confidence, reversibility, production risk, and whether more evidence is needed before acting.
Change guidance
Recommended experiments, query rewrites, index candidates, maintenance checks, or configuration review points with approval gates.
Safety notes
What was not read, what was not changed, what needs staging validation, and which recommendations require a human owner.
Next-step queue
A small action list that separates low-risk checks, deeper investigation, and production changes that need scheduling.
Sample finding
How a finding should be written
Each finding should make the evidence, risk, and next action reviewable by a developer, DBA, or technical owner.
| Field | Sample content |
|---|---|
| Symptom | Checkout latency rises during afternoon traffic spikes. |
| Evidence | Two read-heavy statements account for most visible query time; table growth and index selectivity need review. |
| Recommendation | Run EXPLAIN on representative values, test one index candidate in staging, and confirm write overhead before production rollout. |
| Boundary | No production SQL is executed by the report. A human owner must approve any index, query, or configuration change. |
Boundaries
What this sample report does not claim
The report model is intentionally conservative so it does not overstate automation, certainty, or production safety.
No automatic optimization
The report can recommend checks and changes, but it does not automatically create indexes, rewrite SQL, or tune production settings.
No guaranteed outcome
Findings should describe confidence and risk. They should not guarantee performance improvement before testing.
No broad engine promise
This page is a broad report model. PostgreSQL has the current specialist path; MySQL and SQL Server remain planned surfaces.
No unrestricted access need
A useful audit starts from safe evidence and explicit constraints, not production write credentials.
Ready to prepare scope?
Review the database optimization checklist and audit FAQ before asking for audit scope. PostgreSQL teams can also view the more specific PostgreSQL sample report.