undo + snapshots

think of your database like a document you're editing. most databases only keep the latest version — change something by mistake and the old value is gone. briven keeps a history of save-points instead, like the save-points in a video game or the version history in a Google Doc.

• snapshot — a save-point of your entire database at a moment in time.
• undo / restore — jump your data back to any earlier save-point.
• history — see what changed, when, and roll back just the part you want.

because nothing is ever truly overwritten, you can experiment fearlessly — there's always a way back.

neon, supabase and the rest give developers point-in-time backups, but no non-coder undo. briven's version history is a product feature, not a buried admin tool — surfaced in plain language so anyone can use it. that's possible because the engine underneath (DoltGres) treats every commit like git does: cheap, instant, and fully reversible.

in the dashboard, open your project and use the Snapshots panel:

• take a snapshotbefore any big change (e.g. importing a spreadsheet). give it a name you'll recognise — “before price update”.
• automatic snapshotscan run on a daily / twice-daily schedule with a “keep the last N” rule, so you always have recent save-points without thinking about it.
• restore picks a snapshot and rolls the whole project back to it. the current state is itself snapshotted first, so a restore is never a dead end.

you never need to type a command. the sections below are for developers who want to know exactly what happens underneath, or who want to drive it from SQL.

DoltGres is “Git and Postgres had a baby” — it speaks the postgres wire protocol (so briven's normal postgres drivers, psql, and your SQL all just work) but stores data the way Dolt does: as a versioned commit graph. Git versions files; Dolt versions tables.

briven turns on commit-on-write for every project database, so each saved transaction becomes its own undoable commit:

-- briven sets this on every data-plane connection:
SET dolt_transaction_commit = 1;

-- from then on, a normal write IS a version-controlled commit
INSERT INTO products (id, name, price) VALUES ('p1', 'Chair', 4900);
-- the database HEAD now points at a new commit containing that row

there is no DoltGres CLI— all version control is done through SQL functions and system tables. these are the ones briven's snapshot/undo features call for you:

see the history of a project database (every commit, newest first):

SELECT commit_hash, committer, message, date
FROM   dolt_log
ORDER  BY date DESC;

-- the exact version the database is on right now:
SELECT DOLT_HASHOF('HEAD');

take a named snapshot(what the dashboard's “take a snapshot” button does):

-- stage everything + commit it as one save-point
SELECT DOLT_COMMIT('-A', '-m', 'before price update');

-- tag that commit with a friendly snapshot name
SELECT DOLT_TAG('before-price-update', 'HEAD', '-m', 'before price update');

-- list every snapshot/tag
SELECT tag_name, message, date FROM dolt_tags;

see exactly what changed between two points:

-- table-by-table summary of changes since the last commit
SELECT * FROM dolt_diff_summary('HEAD~1', 'HEAD');

-- row-level diff of one table between a snapshot and now
SELECT * FROM dolt_diff('before-price-update', 'HEAD', 'products');

undo / restore — roll the database back to a snapshot:

-- jump the whole database back to a named snapshot
SELECT DOLT_RESET('--hard', 'before-price-update');

experiment on a branch without touching live data, then merge if you like the result:

SELECT DOLT_BRANCH('experiment');     -- create a branch
SELECT DOLT_CHECKOUT('experiment');   -- switch to it
-- ...make changes safely...
SELECT DOLT_CHECKOUT('main');         -- back to live
SELECT DOLT_MERGE('experiment');      -- bring the good changes in

realtime note: DoltGres has no LISTEN/NOTIFY, so briven's realtime layer watches DOLT_HASHOF('HEAD') per project and pushes an update the moment a commit advances it — see realtime.

three related projects share the same git-for-data engine. briven uses one of them:

• Dolt — the original: a SQL database you can fork, clone, branch, merge, push and pull like a git repo. mysql-dialect. this is the conceptbriven's undo is built on.
• DoltGres — the postgres-dialect version of Dolt. this is what briven runsfor every customer's data, so the whole platform stays on the postgres protocol.
• DoltLab — a self-hosted, GitLab-style collaboration server for Dolt databases (a remote you push to, with pull-request review). it is not a database engine, and briven does not use it — briven embeds the DoltGres engine directly and provides its own dashboard. listed here only so the ecosystem is clear.