Letting AI agents touch your Postgres?

Some agent mistakes are permanent.BasaltDB makes them reversible.

Let your agent work on your real Postgres. It can't drop a table or change more than 50 rows at once, and if a whole job goes wrong, you undo that job. Anything your team or your app changed since stays as it is.

Try it on your database Star on GitHub

Free, Apache-2.0, built in public. No download yet: you build it from source.
Works with Supabase, RDS or a Postgres you host yourself, and any agent that supports MCP.

~/acme

┃ Qualify this week's leads

⚙ basalt_write Qualify leads 1 to 3 ✓ Applied: 3 rows in leads. Saved, can be undone. run r_81 · 41ms

┃ Also drop the old leads table

⚙ basalt_write Remove the old table ✗ Refused: agents can't drop or change tables. Ask the person to run it.

── next morning · your shell ──────────────

$ basalt revert --run r_81

◆ Undo "Qualify this week's leads"

├─ ↩ restore leads #1 QUALIFIED → NEW

├─ ↩ restore leads #3 QUALIFIED → NEW

└─ • keep leads #2 changed after the agent

✓ Undone 2 restored · 1 kept as it was

Illustration. Real output is JSON and plain text, and undo asks for your passkey.

Every change your agent makes

Saved so you can undo it, or it never runs.

BasaltDB checks every write before it touches your data. Everyday changes go through and are saved with their old values. Changes to the tables themselves, and bulk changes, are refused.

Saved, can be undone

Adding and updating rows. Every change keeps its old values for 30 days.

Never runs

Dropping or changing tables, or touching more than 50 rows at once. Those are yours to run.

Your agent's request meets BasaltDB first. An update to 3 leads goes through to your Postgres and is saved so it can be undone. A DROP TABLE on leads never runs.

A timeline of one agent job. The agent changes 3 leads at 14:02, your app marks Birch as paid at 14:20, and the agent changes 27 leads at 14:41. Undoing the job puts back the agent's changes. Birch stays as your app left it, and it is listed as changed after the agent.

Undo

Undo your agent's job. Keep everyone else's work.

A backup restore takes everything back to last night, including the orders your customers placed this morning. BasaltDB undoes only what the agent did. Rows your team or your app changed after it stay as they are, and you get a list of them.

The BasaltDB engine runs next to your agent and connects to your Postgres. Your Postgres keeps your own tables, customers, orders and leads, plus the basalt_meta schema, with BasaltDB roles and triggers on the tables you guard. basalt uninstall removes them.

Your data stays yours

Your data stays in your Postgres.

BasaltDB runs next to your agent and adds one schema, its own roles, and triggers on the tables you guard. It never copies your data anywhere. If you change your mind, basalt uninstall removes everything it added to your database.

Your Postgres

Supabase, RDS or self-hosted.

Your agent

Any agent that supports MCP, in a terminal or a chat.

Your code

Apache-2.0. Read it, run it, fork it.

What it won't catch

We'd rather tell you now.

BasaltDB catches what it can see in your database. Some mistakes happen elsewhere.

A single change that's allowed but wrong. You can undo it, but nothing stops it first.
Emails sent or payments made because of bad data.
Data your agent already read and passed on somewhere else.
Undo after 30 days. Old values are kept for 30 days.
An agent that holds your own admin password.
Time-critical or mission-critical systems. It isn't built for those.

Read the full list of limits

Get started

Three steps on your own database.

1Build basaltgo build -o basalt ./cmd/basalt
2Guard your databasebasalt init
3Connect your agentbasalt mcp --agent my_bot

The quickstart ends with you running the session from the top of this page on a sample table. Open the quickstart

Let your agent do the real work.

Build BasaltDB, point your agent at your database, and keep a way back.

Try it on your database Read what it won't catch

BasaltDB · Apache-2.0