Git for Postgres data, built for agents

Gnomon is a PostgreSQL extension that gives your database branches, history, merges and undo. Give an agent its own branch of your real database, as nothing more than a connection string. See every field it changed, merge it into main when it's right, and undo it if it wasn't.

Gnomon runs inside the Postgres you already have. One extension, no copies, no second database.

Your first branchCopy Anchor Link

Install the extension, then take a branch, change something on it and look at what changed:

create extension gnomon;
select gnomon.track('orders');                    -- history starts now, no backfill

select gnomon.create_branch('agent/refunds');
select gnomon.use('agent/refunds');

-- Every query from here on runs on the branch
update orders set status = 'refunded' where id = 4182;

select * from gnomon.diff('agent/refunds');       -- every row and field it changed
select gnomon.merge('agent/refunds');             -- three-way, type-aware, conflicts as rows
select gnomon.undo_merge(1);                      -- and back

A branch reads everything from main and keeps only what it changes, so it opens instantly and copies nothing, however big your database is. Your application doesn't change: point a session at a branch and the queries it already runs read and write the branch instead of main.

Follow the tutorial →

Hand one to an agentCopy Anchor Link

One command gives an agent a database role, a branch of its own and a connection string. It reads and writes its branch, and the database refuses the rest, main included, even when the agent asks for it by name.

gnomon agent create support-bot

Merging is for the people you choose, or for an agent within rules you write: at most twenty rows, only these tables, every check passing. Postgres enforces them, whatever the agent is told.

Agents → · Runs and the SDKs → · The MCP server →

Where to go nextCopy Anchor Link

• Concepts: branches, coordinates and how a merge decides.
• Branches: what works on a branch, and how a branch write behaves.
• Merges: counts that add up, JSON merged key by key, conflicts as rows, undo.
• Review: diffs, change requests, checks and approvals that go stale.
• History: read any moment exactly, blame a field, bisect a failing check.
• The change feed: every change, in order, to Kafka, NATS, a webhook or a file.
• SQL reference and CLI reference.
• Operations and security when you put it into production.