Skip to content
BasaltDBBasaltDB
Star

FAQ

View as Markdown

BasaltDB is the action ledger for AI agents on a Postgres you already own. It guards a database you run and keeps a record of what agents did there. Your data stays in your Postgres. BasaltDB adds the basalt_meta schema, its own roles, and triggers and policies on the tables you guard. basalt uninstall removes all of it. See What is BasaltDB.

An engine you run on your own computer needs nothing hosted. The engine runs next to your agent, the guard runs inside your Postgres, and the pages where you approve and undo are served from your machine.

An engine your bot runs on its own computer is different. Its approval and undo links open on the hosted BasaltVault portal, portal.basaltvault.app, and you paste the code the page shows back into the terminal. The hosted relay that would carry short links to such an engine is not finished, so links today are long links. See A bot on its own computer and Architecture.

Supabase, RDS and a Postgres you host yourself. It needs a role that can create roles. Connect directly or through a pooler in session mode. A transaction pooler has not been checked. Each host has its own notes in Hosts.

Agents that speak MCP. There are setup steps for OpenCode, Claude Code, Codex and a bot on its own computer in Connect an agent.

The limits are enforced by roles and triggers inside your Postgres. They hold on any path, so an agent that opens a direct connection with its own credential meets the same checks. A prompt asks the model to behave. The guard refuses the statement. See Rules.

What if the agent does something valid but wrong?

Section titled “What if the agent does something valid but wrong?”

A one-row update to the wrong value is valid SQL and goes through. It is saved with the reason the agent gave and the values it replaced, so you can see it and undo it. Nothing stops it first. Changes of 11 to 50 rows and every delete are held for you, and more than 50 rows never run. See What BasaltDB won’t catch.

What if my team or my app changed a row after the agent?

Section titled “What if my team or my app changed a row after the agent?”

Undo leaves that row as it is. It restores the rest and lists the rows it kept. See Undo.

BasaltDB limits the damage and leaves a trail. An injected instruction cannot drop a table, change more than 50 rows in one action, or approve its own change, and every action is recorded with its reason. It does not stop an agent from passing on data it has already read. See What BasaltDB won’t catch.

Can I give an agent write access to production?

Section titled “Can I give an agent write access to production?”

For internal tools, back-office data and small-business bots, yes, and that is what BasaltDB is for. It is not built for time-critical or mission-critical systems, or for teams that need compliance tooling. If a wrong write costs more than undoing it can fix, keep the agent read-only.

BasaltDB is free and released under Apache-2.0. BasaltVault is a separate paid service for many agents and machines. It is not open yet. Prices are not published. See License.

Run basalt uninstall on your own computer. It drops the basalt_meta schema and the basalt_* roles. Your tables and rows stay as they are. The record of what agents did goes with the schema, so you cannot undo agent runs afterwards. See Remove BasaltDB.

In your Postgres. Your tables are not copied or moved. The ledger and old values are in the basalt_meta schema in the same database. The engine’s config and the agent’s scoped credential sit on the machine where the engine runs.

An engine you run on your own computer sends nothing to a service of ours. If your bot runs the engine, its approval and undo links open on the hosted BasaltVault portal.

The AI your agent uses still sees what the agent reads. See Architecture.

Everything these docs describe works today when you build BasaltDB from source. The honest list of what it does not do is on What BasaltDB won’t catch.

Privately, through GitHub. See Security.

BasaltDB · Apache-2.0