A slow application is not automatically a database-sizing problem. The delay may come from a query, a connection limit, a lock, an external service or the way the application requests data. A useful PostgreSQL audit begins by locating the bottleneck.
Provide a workload picture
Describe the slow user journeys, when they occur and how the issue is measured. Provide approved query examples, approximate table sizes and relevant application changes. Prefer anonymised or staging data where possible.
Ask the consultant to record a baseline before changing configuration. Include both typical and busy periods. An improvement measured on an empty test database may not transfer to the live workload.
Require an evidence-led review
The audit should connect each recommendation to an observed issue. Request investigation of query plans, indexing, connection behaviour and contention where relevant. Ask what additional write cost or storage an index would introduce.
PostgreSQL's EXPLAIN documentation is the primary reference for interpreting execution plans. Analysis that executes queries must be authorised and designed carefully around production effects.
Turn findings into a change plan
For each proposed change, require the expected benefit, evidence, deployment method and rollback approach. Separate quick improvements from structural changes requiring application work.
Acceptance should compare the same workload before and after, including correctness and resource use. Faster responses are not a success if results become incomplete or writes start failing.
Ask for a final report your next engineer can understand: affected queries, measurements, changes made and remaining risks. A database specialist should leave this record rather than only a list of configuration values.