Nightly pg_stat_statements baseline drift sentry

On a nightly schedule, this workflow reads pg_stat_statements directly from Postgres to capture per-statement mean execution time, total calls, and tail latency. It compares the current snapshot to a rolling 7-day baseline stored alongside it, ranks statements by how far their mean and 95th-percentile timing drifted upward, and posts the worst offenders to Slack with the normalized query text and call volume so the team can triage at standup.

Use this when you do not have a deploy webhook to hang regression checks on, or when slow creep matters as much as deploy-time spikes — index bloat, plan flips, and growing tables that degrade gradually. It gives a daily heartbeat of which statements are getting slower regardless of release cadence.

1. 1Nightly schedule trigger fires.
2. 2Query pg_stat_statements for mean time, calls, and tail timing per normalized statement.
3. 3Compare to the stored 7-day rolling baseline and compute drift.
4. 4Filter to statements whose drift exceeds the regression threshold.
5. 5Write the new snapshot back as the next baseline.
6. 6Post the ranked regressions to Slack with normalized SQL.