Read-only user Postgres audit
Database Optimization Tool is built for teams that want useful PostgreSQL evidence without handing over write permissions or privileged database control.
Answer-first summary
A read-only Postgres audit can still identify many query, index, bloat, and maintenance risks. The key is to be explicit about what the role can and cannot read.
What a restricted role can still reveal
A restricted role can still reveal table size, index usage, scan pressure, vacuum metadata, visible settings, and extension data when grants allow it.
Why local export matters for cautious teams
The collector runs locally and exports evidence for review, so cautious teams can inspect what was collected before sharing a report or planning changes.
What this page cannot promise
Database Optimization Tool cannot discover facts hidden from the database role, cannot escalate permissions, and cannot apply changes after the audit.
RelatedLinks for neighboring audit problems
Use these focused guides to compare query pressure, index decisions, and maintenance signals before you change production.
Frequently asked questions
These answers stay inside the current Database Optimization Tool product boundary: read-only collection, evidence-gated findings, and human-reviewed next steps.
Can this run without superuser access?
Yes. A read-only role without superuser can still collect useful catalog and statistics evidence when grants allow it.
Can the audit return results without pg_stat_statements?
Yes, with weaker query visibility. The report can still use table, index, scan, size, and vacuum signals while marking the pg_stat_statements gap.
Why read the collector docs before running it?
The /docs/collector page explains local export behavior, required grants, and what evidence leaves your environment.
Why doesn't the report give commands to run immediately?
Permission-limited evidence needs human validation. The report avoids direct production change commands and leaves execution to your team.