I built pg-regression-radar to investigate a question that comes up during database incidents: which Kubernetes deployment made this PostgreSQL query slower?
It uses pg_stat_statements, statistical change detection, and deployment events from Kubernetes, Argo CD, Argo Rollouts, or Flux to connect a query regression with a deployment revision.
This is an early open-source project, not a polished commercial product. I’m looking for people running PostgreSQL on Kubernetes who are willing to try it and tell me where the idea or implementation falls short.
Feedback on installation, false positives, security, integrations, and documentation would be especially useful. Contributions are welcome too: GitHub - joao00001/pg-regression-radar: Detects Postgres query performance regressions and pinpoints which Kubernetes deployment caused them. · GitHub
How do you currently investigate whether a deployment caused a PostgreSQL query regression?
I’ve run into this during PostgreSQL incidents where query latency changes appear close to a rollout, but correlating pg_stat_statements with deployment revisions is still manual. Combining statistical change detection with Argo or Flux events looks useful, especially if it can separate plan changes from normal workload shifts.
That’s exactly the kind of workflow I’m trying to improve. The goal is to make the deployment revision part of the regression context instead of leaving the correlation as a manual investigation step.
Plan-change detection is also an important direction. The project currently supports optional plan capture and plan-diff context, but I’m still interested in learning how useful that signal is in real incidents and how to distinguish plan changes from workload-driven latency shifts.
The plan-diff context seems most useful when pg_stat_statements shows a latency shift without a matching deployment change, since that separates plan changes from workload noise.
Hmm the current detector is primarily deployment-anchored, so this sounds like a good direction for extending it without turning it into a generic APM system. A useful first experiment would be to reproduce three cases:
- a deployment causes a plan and latency change
- a plan changes without a deployment, followed by a latency regression
- latency changes because of workload variation, without a meaningful plan change
In your experience, which plan changes are most useful to surface first? Index scans turning into sequential scans, join strategy changes, row-estimate changes, or something else?
Join strategy changes are usually the clearest first signal because they can explain a sudden latency jump without requiring a schema change. I’d surface sequential-scan flips and large row-estimate changes before smaller cost differences.
The join-strategy flip is the clearest first signal, especially alongside a large row-estimate miss; that pairing is easier to separate from normal workload noise.
Yeah, I’ve been trying find some time to test it or improve the project, but it’s hard as I have a job. Are you able to test it or talk to someone with interest on it?