The database’s own flight recorder
Every schema change is recorded as it happens and attributed to the login that made it. A change an agent made at 3am is distinguishable from one you made, and any entry is a way back.
Who, what and where
Who
The actor, an email or an agent such as agent-alice, and whether it was a person or an agent.
What
The command, the object and the full statement, for every change to a table, view, index, function, type or privilege.
Where
The branch, the session, and the tool as the client reports it (application_name, for example cursor/opus).
Tamper-evident, then insider-proof
The table is append-only and every row is hash-chained to the one before it, so an edited or deleted entry breaks the chain and fox blackbox verify finds it.
A database superuser could rewrite the rows and every hash after them. Anchors close that gap: every few minutes the engine signs a checkpoint of the chain with a key the database cannot read, and writes it outside the database. Copy them to an S3 bucket in Object Lock compliance mode and nobody can remove them, the bucket owner included.
- Tamper-evident for free: the hash chain and fox blackbox verify are in every edition.
- Insider-proof in Enterprise: signed anchors on a schedule, kept where your own admins cannot rewrite them.
- Checking anchors stays free in every edition, including the standalone fox-verify.
- The recorded actor is the login, which a client cannot change. An application that shares one login between many people is recorded as that login.
What it records, and what it does not
So that nobody has to take “every change” on trust.
- Recorded as it happens: CREATE and ALTER of tables, views, indexes, functions, types, triggers and policies; DROP of tables, views, indexes, sequences, schemas, types and functions; GRANT and REVOKE, though the entry does not name the object; TRUNCATE by anyone; an agent’s UPDATE and DELETE; every change the guardrails refused.
- Not recorded: reads; a person’s INSERT, UPDATE and DELETE; dropping a trigger, policy, procedure, aggregate or foreign table; sequences, new schemas, extensions and comments.
- Never seen by the event triggers, because they sit outside any one database: roles, role memberships, databases, tablespaces and settings. Other databases in the same Postgres are not recorded at all.
- A database superuser can stop the event triggers for a session or for everyone, and what they change then is not recorded. Clients and agents log in without that power, so they cannot.
- The next release adds a catalog scan: every five minutes it compares the schema with what it saw last, and records what the triggers missed and the global objects above, with who made the change marked unknown.
A way back, not only evidence
Point at any entry and get a new branch holding main exactly as it was just before that change, with main left alone. It restores a base backup and replays WAL, so it takes a few minutes.
$ fox blackbox entries $ fox blackbox branch-before 42 --as before-the-drop $ fox blackbox verify
Bring a branch’s changes back to main
What is applied is the Blackbox’s own record of what ran on the branch, each statement still attributed to whoever wrote it. Schema only; no data is moved.
- 1
Ask
fox branch request dev --to main lists what dev has that main does not. Nothing is applied yet.
- 2
Review
fox request show 3 prints the statements in the order they ran.
- 3
Approve
fox request approve 3 applies them to main in one transaction. An agent can ask, never approve its own.
A security log beside it
What it records
Sign-ins and failed ones, sign-ups, API keys made and revoked, password changes, admin grants and every refused request.
How it is protected
Chained and anchored the same way as the Blackbox, and free in every edition: fox audit and fox audit verify.
Put your schema on the record.
Every schema change is recorded from the moment you install. Verifying it is free, forever.
$ curl -fsSL https://get.thefoxbyte.com/install.sh | sh