Problem library

Diagnose the production symptom before prescribing the fix.

These pages explain what evidence to collect, common wrong assumptions and when a deeper performance investigation is justified.

Request an investigation See sample report

Problem guide

High PostgreSQL CPU

Separate workload concentration, bad plans, I/O pressure and application amplification before scaling hardware.

Problem guide

Connection exhaustion

Distinguish pool behavior, long transactions, application storms and server-side limits.

Problem guide

Lock contention

Find blockers, lock queues, long transactions and DDL interactions from evidence.

Problem guide

Plan regression

Compare plan shape, row estimates, data distribution and deployment/version changes.

Not sure which problem you have?

Production symptoms overlap. High CPU can come from one expensive statement, from many cheap ones, or from a plan that changed. Connection errors can be a pool sizing problem or the visible end of a lock queue. Start from these three questions:

What are sessions waiting on? Group pg_stat_activity by state, wait_event_type and wait_event. Active sessions with no wait event are usually running on CPU; Lock waits point to contention; many idle in transaction sessions point to the application.
Which statements dominate total time? Rank pg_stat_statements by total_exec_time, not by the slowest single call. See high CPU.
What changed? Deploys, migrations, data growth, version upgrades and parameter changes. A sudden change in one statement's mean time with the same call count points to a plan regression.

The read-only evidence collector captures all three in one run.

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.

Request an investigation See sample report