Independent developer Denislav Gavrilov shipped diffium-db, an open-source terminal UI that stays open next to a Postgres database and shows, in real time, what an agent, a migration, or a person just changed. Take a baseline snapshot, leave the watcher open, and every second it looks again. Changed objects stack up in the left pane; the right one renders what the change actually did.
The problem it targets is specific. git diff shows the migration file an agent wrote, not what that migration actually did once it ran, and it says nothing about a row the agent updated in passing because doing so seemed reasonable at the time. Standard schema-diff tools only compare two database states after the fact. Nothing has, until now, sat open during the work itself.
The gap this tool fills is easy to underestimate: reading an agent’s transcript tells you what it intended to do, while a live database diff tells you what it actually did to persistent state, and those two things diverge more often than teams expect once an agent is given real write access. A transcript can describe a plan that never executed cleanly, or hide a side effect the agent’s own summary omitted. diffium-db is built around the assumption that the state itself, not the agent’s account of it, is the source of truth teams need to inspect.
Structural changes (columns, indexes, constraints, triggers, views, enums, functions) get an exact line-level diff, because diffium-db renders every object into one canonical, deterministically ordered block of text and diffs the text. Row changes are harder to verify honestly. The tool fingerprints each row with its primary key plus an MD5 hash rather than storing full copies, which distinguishes inserts, updates, and deletes cleanly, until a table gains a new column and every hash in it shifts at once. Gavrilov’s fix is to flag that ambiguity rather than hide it: the interface marks an affected row count with a question mark and a note explaining that the update figure is a guess, while insert and delete counts, which depend only on the primary key, stay exact.
Gavrilov recommends running the tool against a disposable database branch rather than production, citing Neon’s copy-on-write branching as the workflow he uses himself: create a branch, point diffium-db at it, let the agent work, review the diff, and either apply the change to the real database or delete the branch. He reports a branch creation time of about 1.2 seconds in his own testing, though that figure describes his single run rather than a documented benchmark.
The tool is Postgres-only in this release, knows nothing about your ORM (so a new column arrives unattributed to any model definition or migration), and polls instead of following a replication stream. Gavrilov lists all three as open. It is available on GitHub under the MIT license.
For any team letting agents run schema migrations or write directly to a shared database, the practical move is to pair the agent with a disposable branch and a running diff, so a bad change is caught on a copy before it reaches the database anyone depends on.
Reported by Denislav Gavrilov on his own site, August 30, 2026.
