Metadata and statistics
Safe inputs can include query statistics, index definitions, table sizes, growth signals, wait notes, version details, and hosting constraints.
Safety boundary
A read-only database audit should keep production changes outside the evidence step.
This page defines the access boundary for cautious database optimization work: what can be reviewed, what should not be requested by default, what is not saved here, and what still requires human approval.
Access model
What read-only means here
The first audit step should collect enough evidence to reason about performance without giving a tool production control.
Representative examples
You can share sanitized slow queries, EXPLAIN output, endpoint symptoms, or snapshots when direct access is not appropriate.
Temporary scoped access
If access is used, it should be limited, documented, and removable after evidence collection. Avoid broad owner credentials.
No production writes
The audit evidence step should not run migrations, create indexes, modify tables, update rows, vacuum tables, or change configuration.
No automatic SQL changes
Recommendations can include SQL or index candidates, but execution belongs to a human-approved rollout process.
No secret dumping
Do not send passwords, full dumps, private customer data, or unrestricted cloud credentials through this broad site.
Decision table
What the audit can and cannot do
Use this boundary before involving production systems or sending database evidence outside your team.
| Question | Boundary |
|---|---|
| Does it need database credentials? | Not always. Start with exported evidence or sanitized examples. If credentials are used, prefer temporary read-only access. |
| Does it read production data? | It should prefer metadata, statistics, plans, and samples. Sensitive row data is not required for the broad preparation path. |
| Does this site save user data? | This static site does not provide upload, account, or hosted collector storage. Do not paste secrets into it. |
| Will it execute write operations? | No. Production writes, index creation, SQL rewrites, and configuration changes require separate human approval. |
Human approval
Where review must stay manual
Read-only evidence can identify likely next steps. It cannot make production risk disappear.
Before collecting evidence
Confirm what data can be shared, who owns access, and whether snapshots are safer than direct database reads.
Before testing recommendations
Review proposed queries, index candidates, maintenance checks, or configuration changes in a non-production path first.
Before production rollout
Assign an owner, rollback plan, maintenance window, monitoring check, and clear approval before any change is applied.
Before expanding scope
If the issue is PostgreSQL-specific, move to the specialist collector path instead of broadening access on the main site.
Need a safer request?
Use how it works and the request checklist to describe symptoms and constraints first. PostgreSQL teams can review the PostgreSQL collector path.