Finished report preview
Sample output
See what a useful database audit feels like
Preview the report customers see after evidence becomes priorities, owner notes, risk language, and next checks. Then create a project for builder work or move to live review when your database already exists.
Owner-ready findings
collector-backed evidence
benchmark-backed validation
Owner summary
Start here if you need the plain-English version. The report turns database symptoms into product impact: slow checkout, delayed admin screens, heavier jobs, and rising cloud spend. Each finding names the likely owner, the business risk, and the first staging check before anyone touches production.
Best first click
Skim the sample, then create a real project at /projects/new. Use the project builder when you are planning a schema or cleaning up a design. If you already have a live database, the collector path comes next: create audit.json, upload it, and compare the live review with this sample shape.
What the sample shows
This page is a finished example, not a diagnosis of your database. It shows the review format: priority, owner translation, evidence, business risk, and a concrete next check. A real upload replaces the sample evidence with your own audit.json inside the account workflow.
Evidence levels in the sample
The sample distinguishes SQL draft, schema-backed, plan-backed, collector-backed, and benchmark-backed evidence so a plausible recommendation does not look like a validated rollout. Collector-backed findings rely on audit.json workload history; benchmark-backed findings require staging or sandbox comparison before production work.
Path from sample to live review
Use the sample to decide whether the report style is useful. For a database you are still designing, create a project and continue in the project builder. For a database already serving traffic, follow the collector docs, generate audit.json from your own environment, then run the live review from the collector workflow.
P1: Sequential scan pressure on public.orders
Owner translation: frequent full-table reads can turn normal order lookup traffic into slow pages and higher database load. Business risk: checkout or support workflows may degrade as volume grows. Who should handle it: database engineer or Postgres consultant. Next step: run EXPLAIN (ANALYZE, BUFFERS) on the top order lookup query before adding a composite index. Evidence: high seq_scan and seq_tup_read relative to indexed access.
P1: Temp writes in a top query
Owner translation: a slow query may be spilling sort or hash work to disk, which makes response time less predictable. Business risk: reports, dashboards, or background jobs can crowd out customer traffic. Who should handle it: database engineer, with app owner confirming which workflow uses the query. Next step: inspect sort/hash operations and test work_mem or index changes in staging first. Evidence: temp_blks_written is present on a high total_exec_time query.
P2: Unused non-unique index candidate
Owner translation: the database may be paying write and storage cost for an index that is not helping reads. Business risk: every insert or update can carry avoidable overhead, but dropping the wrong index can cause a regression. Who should handle it: database engineer after dependency review. Next step: compare dependency and query coverage before dropping or rebuilding any index. Evidence: index size is material and idx_scan is zero.
AI Upgrade Lab advisory
The AI section adds review momentum: diagnostic prompts, reversible index experiments, verification checks, and rollback notes. The source findings still stay evidence-led, so advice is useful without pretending to be a completed production change.
FAQ
Frequently asked questions
These answers describe the product focus: careful database evidence, clear findings, and team-approved next steps.
Why does the sample output mention EXPLAIN?
EXPLAIN is the checkpoint between a plausible idea and a production-ready database change.
Can the report surface temp write pressure?
Yes. Query findings can include temp_blks_written and related pressure signals so teams know when sorts or hashes are likely spilling to disk.
Does the sample include table maintenance signals?
Yes. The report format is designed to keep query findings, index candidates, and autovacuum or dead-row warnings in the same review flow.
Can I compare this sample with a real collector upload?
Yes. Use the sample to learn the report shape, then run a live review with your own audit.json when you have an existing database to inspect.
What should I do after reading the sample?
Create a real project at /projects/new, then use the project builder if you are planning changes. Use collector upload when you already have production or staging evidence to review.