Free tool
From this major to that one: what stops working?
Not the release notes, and not a feature list. The changes between two majors that move something your monitoring reads, ranked so the ones that fail without an error come first.
Run it on your numbers
The check-up query reads this from server_version_num.
Paste them from your exporter configuration, your dashboard queries or your runbook. Anything that looks like an identifier is matched; the rest is ignored.
The upgrade that succeeds and takes the dashboards with it
An upgrade is rehearsed on staging, the application is exercised, the cutover goes to plan, and a fortnight later somebody notices that the checkpoint panel has been flat since the Tuesday. Nothing errored. The exporter asked for a view that still exists, got a shape it did not expect, and wrote nothing. Alerting on that panel had no data to fire on, so the silence read as health.
That is the class of change this page ranks first. A view that was dropped announces itself the moment a scrape runs; a column that was renamed, a counter that moved to a new view, a setting that stopped being a boolean and became a list — those are found later, by hand, by someone asking why a number looks wrong. The release notes contain all of them and are organised by what was built rather than by what will break.
Why this asks what your exporter reads
Between two majors there are dozens of changes and only a handful that touch you. Which handful depends entirely on what your monitoring queries name, and that is the one thing no release note can know. So the box above takes whatever you have — the scrape configuration, the queries behind a dashboard, the runbook nobody has opened in a year — and matches identifiers against the surfaces each change touches. Anything that looks like an identifier is used; the rest is thrown away without being read.
A clean result is worth something and is not a guarantee. A query that assembles a view name at runtime will not be in your paste, and neither will the dashboard somebody built in a hurry and never checked in. Treat an empty match as the absence of known risk rather than the presence of safety, and read the silent list anyway.
Support dates are a deadline, not a countdown
The two support figures above are the same dates PostgreSQL publishes, put next to the work they imply. After a final minor release there are no more fixes, which matters most for the bugs found in the months afterwards: they are fixed on a version you are not running, and the patch you want is only available by doing the upgrade you were putting off.
The practical reading is that the deadline for deciding is a long way before the deadline for finishing. Crossing four majors means four sets of monitoring changes absorbed at once, an extension audit, and a rehearsal that is worth doing twice. Each change in the list has a page of its own with the query run on both versions, so the work of the upgrade can start as reading rather than as a meeting.
Nobody wants to be the one who ran the query too late.
DBExplore watches the numbers behind these checks on every cluster it is pointed at, and asks before it changes anything. We onboard design partners in small batches.