How it works

The client keeps production control.

No credentials or production access required: your team runs read-only collection and shares the resulting evidence bundle.

01

Scope

Define the production symptom, business impact and evidence boundary.

02

Collect

Client-run read-only evidence: workload, plans, locks, indexes and relevant settings.

03

Investigate

Correlate signals and distinguish the symptom from likely root cause.

04

Prioritize

Rank findings by impact, confidence, risk and implementation effort.

05

Validate

Define rollback and before/after checks so the team knows whether the change worked.

Step by step

  1. Fit review. You describe the symptom, platform and version through the contact form. I reply with whether a bounded investigation fits, what question it would answer and which evidence is needed. If it is not a fit, you get that answer instead of a proposal.
  2. Scope agreed. One cluster, one dominant workload and one decision: for example, why p95 latency doubled after a release, or whether the instance really needs to be larger. Price and delivery are confirmed before any paid work.
  3. Your team collects evidence. Run the read-only collector as a pg_monitor role, once in a normal period and, if possible, once while the problem is happening. Add representative EXPLAIN (ANALYZE, BUFFERS) output from a safe environment, a short change timeline and, on RDS or Aurora, Database Insights and CloudWatch exports for the same window.
  4. Review and redact. The output is plain text. Your team reads it and removes anything it does not want to share before sending it.
  5. Investigation. The workload is ranked by total cost, the symptom is correlated with waits, plans, locks, connections and changes, and competing explanations are tested against the evidence. Gaps are raised early rather than filled with guesses.
  6. Report within 5 business days of receiving the agreed evidence. Each finding states severity, confidence, evidence, observation, likely cause, recommendation, risk, rollback and validation. See the sample report.
  7. Review call. A 60-minute walkthrough with your engineers, followed by bounded async clarification. Your team decides what to change and when.

Security and access

  • No database credentials, VPN access or production write access are requested.
  • The collector sets default_transaction_read_only = on, a 30-second statement_timeout and a 1-second lock_timeout for its own session, and reads only statistics and catalog views.
  • pg_stat_statements text is normalized, so literal parameter values are replaced with $1, $2, ….
  • An NDA can be signed before evidence is shared.

Why client-run collection?

It reduces the security hurdle, keeps credentials inside your environment and makes the evidence bundle inspectable before it leaves your control. Read the collector script.

Why not just paste the query into AI?

Because the decision may depend on workload frequency, writes, locks, connections, statistics, platform limits and the cost of changing the wrong thing.

Production evidence

Need an independent PostgreSQL investigation?

Start with the problem and the evidence you already have. You will get a direct answer on whether a scoped investigation is the right next step.

Prefer to talk first? Book a 20-minute triage call.