Hindsight for PostgreSQL

Why Hindsight?

The dryrun CLI answers questions about your database as it is right now. That is most of what you need, and it works offline, which is the whole point of it.

The questions it cannot answer are the ones about time. Is this table growing faster than it was last month? Has that index been unused, or did we just add it? Did this bloat start before or after the migration we shipped two weeks ago? A single snapshot is a point. You need the series.

Hindsight is where the series lives.

It never connects to your database

This is the part 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 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. Hindsight's structural advantage is that it never asks for any of it, which is also what makes it workable in 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.

Findings cover schema change risk, growth and capacity forecasts, bloat with reclaimable bytes, indexes that have stopped taking scans, read amplification from sequential scans, vacuum health, BRIN correlation decay, and shifts in n_distinct.

What is more interesting is what the engine refuses to say. Counters are cumulative since the last pg_stat_reset, so a decrease is treated as a reset and the earlier segment is discarded rather than reported as a cliff. Capture cadence is irregular, so windows are normalized to a per-day rate instead of raw deltas that inflate with the gap. Severity ranks by what a problem costs and how confident the engine is, not by the size of the number, so a forty-fold bloat ratio on a small index stays medium while a two-fold ratio on a large table does not.

Some detectors were cut on purpose. A drop in index scan rate is reported at low severity, because a drop has a benign explanation (traffic fell) that the engine cannot distinguish from a harmful one (a plan flipped to a sequential scan), and overstating it would train you to ignore the card. Statistics 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.

The goal is a feed you still trust in month six.

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.

For your agents

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 schema state, rather than each developer's agent working from whatever snapshot happens to sit in their working copy.

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 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.

Not finished. See below.

Where it is in development

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

The registry, the feed, the engine, 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.

The honest limitation is cadence. Trend findings need a series with enough points to mean anything, and if you push by hand twice you will see an empty engine and 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. Scheduled capture, where Hindsight runs the capture for you, is the next thing being built and is the intended paid tier when it arrives.

Everything else stays free while the alpha runs.