How pg-checkup works

We deliberately do not ask for your connection string on the free tier. Instead you run a small SQL script we publish. It only ever touches catalog and statistics views — pg_stat_user_tables, pg_stat_user_indexes,pg_stat_statements, pg_settings, pg_constraint — and never reads a single row of your application data. A role with pg_read_all_stats is enough.

The output is a JSON file containing aggregate counters and configuration — query shapes (already normalized by Postgres), not query results. You can read the whole script before running it: pgcheckup-collect.sql.

Your bundle runs through a fixed set of rules — the same checks a senior DBA would make on a first pass. Each rule produces a finding with a severity, the evidence behind it, a copy-paste fix, and the expected win. The same input always produces the same report, and nothing is invented.

• Buffer cache hit ratio vs. the 99% target
• Large tables being sequentially scanned (missing indexes)
• Unindexed foreign keys (slow joins & parent deletes)
• Dead-tuple bloat & autovacuum keeping up
• Unused and duplicate indexes (write amplification)
• Expensive queries & N+1 access patterns from pg_stat_statements
• Spilling to temp files (work_mem)
• Untuned config: shared_buffers, random_page_cost on SSD, work_mem
• High rollback ratio & deadlocks

Every finding is written for an engineer, not a DBA. You get the why, the exact SQL to run (with CONCURRENTLYwhere it matters so you don't lock writes), and the expected impact. On Pro, we benchmark the slow query, apply the fix on a shadow copy, and show you the real before/after.

Enable pg_stat_statementsbefore you collect — it unlocks query-level analysis, N+1 detection, and the top time-sinks. The collector tells you if it's missing.