Free tools
A check-up for the Postgres you are responsible for
One read-only query, pasted back into this page, answered by every calculator at once and ranked by how soon each thing hurts. Nothing you paste leaves your browser.
Run one query, get every answer at once
The query below is read-only and is a single statement. Run it on the database you are worried about, paste the row back, and each check answers for your server. The paste never leaves this page: there is no request to make, because the arithmetic is in the page you already loaded.
The report card
Nothing pasted yet, so these are in the order they were built. Once there is a result to read they re-order themselves worst first, and by how soon each one hurts within that.
- Not run Open Wraparound countdown
How long until this database stops accepting writes?
Put the freeze duration next to the freeze deadline. How long the anti-wraparound vacuum has, how long it needs at your throughput, and what raising autovacuum_freeze_max_age costs you.
- Not run Open Upgrade path
What breaks in my monitoring between this major and that one?
Paste the views and columns your exporter reads. Get back the changes between your major and your target that touch them, the silent ones first, and the support clock on both.
- Not run Open Autovacuum trigger
When does autovacuum next visit this table, and how long will it run?
Put the time until the trigger next to the time one pass takes. If the dead rows come back before the vacuum finishes, the threshold is not the problem and lowering it will not help.
- Not run Open Memory budget
Do these settings fit in the RAM this server has?
The worst case rather than the average: work_mem multiplied out by hash nodes, parallel workers and concurrency, plus every autovacuum worker at once, against what the planner is being told to believe.
- Not run Open Checkpoint pressure
Are checkpoints timed or requested, and what does each one cost?
Where the size trigger really sits, which is not max_wal_size, what full-page images cost you at that spacing, and what raising the limit does to crash recovery. Both halves of the trade.
- Not run Open Connections and pooling
How many connections should this server actually allow?
Three numbers that are never on the same page: how many connections are ever busy, how many the server will really accept once the reservations come off, and how many your pools are configured to open.
Why a check-up and not a wall of calculators
Most of the numbers on this page are ones you could work out with a calculator and twenty minutes. The reason nobody does is that you have to know which twenty minutes are worth spending, and you find that out by having the wrong answer first. So these run together off one query and sort themselves: the worst thing you have is at the top, the soonest of those first, with the time on it.
Each check also refuses to restate what you already know. The version you run changes the arithmetic, not just the wording, and every check here is gated on it — limits moved between majors, settings arrived, and views were renamed under monitoring that never noticed. The selector is the first control on the page for that reason.
Nothing you paste leaves this page
There is no request to make. The arithmetic is in the JavaScript that came with the page, so a paste is read, computed and discarded in the browser; the only thing kept is a copy in this browser's own storage, so the page is still useful the next time you open it. Clear the box and it is gone. The query itself is a single read-only statement that touches no counters, assigns no transaction ID and writes nothing.
Your inputs are also in the address bar. That makes a reading shareable: paste the link into a channel and whoever opens it sees the same numbers, without the numbers having gone through a server on the way.
What is here, and what is coming
Running today: wraparound countdown, upgrade path, autovacuum trigger, memory budget, checkpoint pressure, connections and pooling. Each was chosen because it chains numbers you already have rather than restating a default, and each is built the same way: a formula with unit tests of its own, a version selector that changes the arithmetic rather than only the wording, and a verdict stated in time instead of in thresholds.
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.