Hindsight for PostgreSQL

Nobody is watching this database between incidents

Most teams shipping Postgres today do not have a DBA. They have a framework, a migration tool, an agent writing a fair share of the SQL, and an alert that fires once something is already wrong. Alerts handle the acute failures. The slow ones were most of what a DBA was for: bloat creeping up, an index nobody uses, statistics drifting away from reality, a table that will not fit next year's growth, a query that got ten times slower and nobody looked.

All of it is visible weeks ahead in data your database already keeps. It gets missed because noticing it means someone compares this week to last month, on purpose, every week. AI agents will not do it. They see one schema, once, with no history, and start from nothing again tomorrow.

Hindsight keeps looking. Teams pay a consultant to run a Postgres health check a few times a year; this is the same check, automated, running on every push, against a database it never connects to.

The score, and what it is worth

Every database in a workspace carries a score out of 100. It blends four pillars, renormalized over whichever ones have data:

• space: bloat, reclaimable bytes, share of total database size
• maintenance: vacuum health, dead tuple ratios, freeze and multixact age, autovacuum turned off where it should not be
• query cost: regressions and newly costly shapes from pg_stat_statements, weighted by what they actually cost
• structure: unused indexes, read amplification, missing coverage

Durability risk is deliberately kept out of the average and tracked as a separate state. A wraparound clock or a capacity ceiling should not be softened by a good score elsewhere.

The report page ranks every deduction, shows the evidence, and reconciles back to the number, so a score is a way into the detail and not a replacement for it.

It never connects to your database

This is worth being precise about, because it is a permanent design constraint rather than something on a roadmap.

Hindsight does not connect to your database. It does not run EXPLAIN, it does not poll pg_stat_*, and it holds no credentials. The dryrun CLI captures on your side of the network, computes everything locally, and pushes the result. The service stores what it receives and reasons over the accumulated history.

The usual way to get trend analysis is to run a collector inside your infrastructure and give it a connection. That is a real operational commitment: another process to deploy, another set of credentials, another thing to audit, and a security review that takes longer than the integration. Hindsight's structural advantage is that it never asks for any of it, which is also what makes it workable in the environments where handing a vendor a database connection is simply not going to be approved.

A workspace toggle takes it one step further and refuses any push carrying unmasked planner statistics, so a shared workspace cannot accumulate column values nobody meant to send.

What the engine finds

Every push that carries a change fires the engine. It reads the ordered series for that database and emits findings, which stay on the feed as one card per condition, updated in place, until the condition clears.

Some of it is the standard health check, done carefully. Bloat cards state absolute size, reclaimable bytes, and share of the database, because a ratio alone is not triageable, and a moderate case has to also be growing before it earns a card. Unused index findings require several honest observation intervals spanning a real week before zero scans is allowed to mean unused, so an index you added on Tuesday cannot be recommended for deletion on Wednesday. Read amplification reports sequential rows read per day against table size, so a small cached table cannot outrank a large one.

Some of it needs the series and has no single-snapshot equivalent at all. Growth folded into a rate and a forecast, with the evidence window stated. BRIN correlation decay, classified as a one-off reorder or an ongoing drift, because the fix differs. Query shapes compared per node instead of pooled. Statistics on how much you can trust pg_stat_statements itself right now.

What is more interesting is what the engine refuses to say. A drop in index scan rate is reported at low severity, because a drop has a benign explanation the engine cannot rule out. Detectors that tracked data drift rather than plan risk were removed entirely, because there was no safe action to recommend at the end of them. Severity ranks by what a problem costs and how confident the engine is, not by the size of the number, so a fortyfold bloat ratio on a small index stays medium while a twofold ratio on a large table does not.

The goal is a feed you still trust in month six. Every card you learn to ignore costs more than the finding was worth.

What changed, and what it broke

This is the part a monitoring tool cannot do, and it is the reason to keep history rather than just alerts.

Findings are anchored to the capture where the condition began, taken from the series rather than from a row timestamp, so it survives recomputation. When that onset lines up with a schema change recorded on the same object, the card links the two: this index started bloating around the time that column was added.

The wording stays hedged on purpose. It says the two things happened around the same time, never that one caused the other, because temporal coincidence is what the data supports and one confident wrong answer costs more trust than ten cautious right ones.

Answering what changed, and what did it break from history alone is the thing Hindsight is for.

The memory your agent does not have

Hindsight exposes a hosted MCP endpoint, protected by OAuth and pinned to a single database. Point your team's assistants at it and they read the same authoritative state, rather than each developer's agent working from whatever snapshot happens to sit in their working copy.

An agent about to write a migration can ask what condition this database is in, what is already bloating, which indexes are unused, what regressed last week, and get an answer grounded in months of history instead of the schema dump in its context window. The local dryrun MCP server is free, works offline, and is the right starting point. The hosted one is for when a team wants one shared answer.

What Hindsight is not

Not a live collector. No agent in your infrastructure, no connection, no credentials. Permanent, not a phase.

Not an incident detector. A pushed snapshot cannot see the last hour, so Hindsight will never tell you the database is down right now. Keep your monitoring. What Hindsight covers is the slow, compounding kind of problem that turns into an incident weeks later.

Not everything a DBA watches. Replication lag, backup recency, failover readiness, connection pool exhaustion, and patch posture are outside what a snapshot carries, and Hindsight says nothing about them. On a managed platform those are already the platform's job. The condition of the data itself is not, and that is the part usually left to nobody.

Not a replacement for EXPLAIN. Several findings deliberately point you at a query to verify rather than asserting a regression they cannot prove from statistics alone.

Not a compliance product. The audit trail is real and some teams will buy it for that, but the job is an insight stream your team does not have to operate.

What it costs

Hindsight is in alpha, and everything is free during alpha.

The line afterwards: the rough path stays free, and delivery is what gets paid for. Pushing snapshots, the feed, the findings, the score, and the digest read in the app are the free tier, permanently. What you will pay for is not having to do any of it yourself. Scheduled capture, so nothing goes stale when a deploy week gets busy, and the digest arriving by email and Slack instead of waiting for you to remember it exists.

Charging for the score itself would be the wrong trade. It has to prove itself first.

Where it is in development

The registry, the feed, the engine, the score, the digest, workspaces, and the hosted MCP endpoint are built and running. Snapshots you push are content-addressed and verified server-side, so a push is idempotent and what gets stored is exactly what you sent.

Two honest limitations. Setup is still manual: install the CLI, mint a token, add the remote, push. There is no connect-in-a-browser flow yet, and it is the next thing being built. And trend findings need a series with enough points to mean anything, so if you push by hand twice you will see an empty engine and reasonably conclude there is nothing here. Push from CI on every deploy, or on a schedule, and the feed starts earning its place within a couple of weeks.

If you have been running dryrun for a while, you already have the history. Push it with --all and the engine has something to reason over on day one.