Databases for AI agents
Each agent gets its own copy of your PostgreSQL database in a tenth of a second. It can break the copy, reset it, and hand its changes back for a person to approve. The branching plugin for OpenEverest does this on your own Kubernetes.
Why agents need branches
A developer who needs a database usually gets one restored from a backup. With a few gigabytes that takes minutes, and the copy takes as much disk as the original. That's fine once a day. An agent works in loops: change something, run the tests, throw the result away, try again. If every attempt needs its own restored database, the agent spends most of its time waiting, and a hundred agents need a hundred databases.
A branch is a writable copy that shares its data with the source until one of them writes. Making one copies nothing, so it takes the same time for 10 MB or 10 GB, and it uses disk only for what changes. In our tests, 180 branches of a 1.5 GB database took 14 MB.
Branches also give an agent a way back. Reset a branch to the source as it is now. Take a restore point before a risky step and roll back to it. When a person approves the agent's work, promote the branch so the source gets its data; a restore point is taken first, so that can be undone too.
Two kinds of branch
The plugin branches a database into a new database in the same server, or the whole instance into a new server.
Database branch
PostgreSQL 18
PostgreSQL 18 can create a database by asking the file system to clone the source's files (file_copy_method = clone). On XFS, Btrfs or ZFS the new database shares every block with the source. No pod starts and no volume is created: a 10 GB database is branched in 0.13 seconds, and the application connects with the same user to another database name.
The catch: PostgreSQL copies a database only while nobody else is connected to it, so the source's sessions are cut off for the moment of the copy. On an idle database that's a fraction of a second.
Instance branch
PostgreSQL 15+ and MariaDB
A new instance whose volume starts from a copy-on-write snapshot of the source's, taken from a standby when there is one. It has its own pods, CPU, memory, configuration and endpoint, and every database and role of the source.
It's ready in about 25 seconds whatever the size, most of it the server starting. We branched a primary serving 1,450 transactions per second; the longest pause its clients saw was 84 ms. MariaDB instances, with replication or Galera, branch the same way.
| You need | Database branch | Instance branch |
|---|---|---|
| A database for one agent task or CI job | 0.1 s, no new pods | ~25 s and a server each |
| Hundreds of short-lived copies | one server for all of them | a server for each one |
| To branch a busy production database | its clients are cut off briefly | the primary isn't touched |
| Load tests or heavy queries | shares the source's CPU | its own CPU and memory |
| Other settings or extensions | the source's | its own |
| A preview environment with its own endpoint | same endpoint, another database | its own endpoint |
One agent task, timed
We scripted an agent's schema change on a 10 GB PostgreSQL database: add a column, backfill it and index it.
- Branch app into app_agent_19.0.14 s
- The agent gets it wrong: a DELETE without a WHERE, then a dropped table.
- Reset the branch. The data is back as it is in app.0.7 s
- The agent runs the right migration and its tests pass. This is PostgreSQL building an index on 70 million rows.71 s
- A person approves and the branch is promoted. A restore point of app is taken first; the application keeps its connection string.2.5 s
- Roll back to that restore point, if the change turns out wrong.0.4 s
apiVersion: plugin-branching.plugins.openeverest.io/v1alpha1
kind: Branch
metadata:
name: agent-19
namespace: team-a
spec:
instanceRef:
name: orders # the PostgreSQL instance
source:
database: app
database: app_agent_19The Branches tab and the HTTP API create the same resource. Reset, promote and rollback are Operation resources, and restore points are RestorePoint resources.
The broken data never reached app. Branching took 3.7 of the 75 seconds; the rest was the migration.
Use cases
- Agent sandboxes
- Each task gets a database branch that the agent can break and reset.
- Competing agents
- Several agents try different indexes or query rewrites on their own branches. You benchmark them and promote the best.
- CI
- Each job gets a database with real data instead of loading fixtures, and deletes it when it ends.
- Preview environments
- Each pull request gets an instance branch with its own endpoint, deleted when the pull request closes.
- Migration rehearsals
- Run a migration on production-sized data to see how long it takes and what it locks.
- Incident debugging
- Branch production with an instance branch and investigate without touching it.
In OpenEverest
The plugin adds a Branches tab to the instance page.
Branches, restore points and operations
Every branch of the instance with its source, status and how long it took, the restore points, and the recent operations. Each branch has Reset, Promote and Delete; each action is checked against OpenEverest's RBAC as the user who clicks.
Creating a branch
Pick a database to branch into a new database, or the whole instance into a new instance. The dialog says what the storage will do, for example that a ZFS volume counts database branches against its size.
Details
- Kubernetes resources. Branch, RestorePoint and Operation are custom resources, so agents, CI and GitOps apply them like anything else. The UI and the HTTP API create the same objects.
- OpenEverest permissions. Every UI and API request is checked against OpenEverest RBAC as the user who made it. Promote and rollback also need the right to change the instance.
- No superuser. The plugin declares its own limited role in each instance it branches. It doesn't use the superuser or the application's credentials.
- Restarts are safe. Multi-step operations record each step and pick up where they stopped after the plugin restarts.
- Databases. PostgreSQL through CloudNativePG: database branches on 18, instance branches on 15 and later. MariaDB, with replication or Galera: instance branches.
- Storage. Database branches need a file system with reflinks: XFS (the default of modern mkfs.xfs), Btrfs or ZFS. On ext4, the default of most CSI drivers, a branch is a full copy. Instance branches need CSI snapshots that clone without copying, as OpenEBS ZFS LocalPV, Portworx, Ceph RBD and NetApp Trident do. Storage requirements
Learn more
Database Branching for AI Agents: PostgreSQL Copies in Milliseconds, Not Minutes
How both kinds of branch work, and every number we measured on a 10 GB database.
Read the post → DocsBranching plugin documentation
Methods, storage, operations, custom resources, the HTTP API, permissions and installation.
Read the docs →Frequently asked questions
What is an agentic database?
A database that AI agents create, change and delete themselves, through an API, as part of their work. Agents need copies that are fast to make, cheap to keep and easy to throw away, and database branching gives them that.
What is database branching?
A branch is a writable copy of a database that shares its data with the source until one of them writes. Nothing is copied when it's made, so it's ready in a fraction of a second whatever the size, and it uses disk only for what changes.
How is this different from Neon?
Neon branches inside its own storage engine, which separates storage from compute, so a branch's compute starts almost at once. The branching plugin uses standard PostgreSQL and MariaDB on your own Kubernetes and storage. Database branches take about 0.1 seconds. Instance branches take about 25 seconds, mostly the server starting, but there's no storage engine to run and the data stays on your volumes.
Which databases are supported?
PostgreSQL through OpenEverest's CloudNativePG provider: database branches on PostgreSQL 18, instance branches on PostgreSQL 15 and later. MariaDB through OpenEverest's MariaDB provider: instance branches, with replication or Galera.
What storage do I need?
For database branches, a file system with reflinks: XFS on ordinary block storage, Btrfs or ZFS. For instance branches, a CSI driver with copy-on-write snapshots and clones, such as OpenEBS ZFS LocalPV, Portworx, Ceph RBD or NetApp Trident. If the storage clones a volume by copying it, you get a full copy, not a branch.
Does branching affect the production database?
An instance branch is taken from a standby, so the primary isn't touched: with 1,450 transactions per second on the primary, the longest client pause was 84 ms. A database branch cuts off the source database's sessions while it's copied, so use it for development and staging databases, and instance branches for busy production ones.
Is it open source?
No. The branching plugin is a Solanica product for OpenEverest, the open-source database platform, and for Solanica Platform, its enterprise distribution. It's in early access.
Try it on your cluster
The plugin is in early access. Tell us what your agents or CI need, and we'll help you set it up on your own Kubernetes.
PostgreSQL is a registered trademark of the PostgreSQL Community Association of Canada. MariaDB is a trademark of MariaDB plc. Neon is a trademark of its owner. Solanica is not affiliated with, endorsed by, or sponsored by these organizations. These names are used for identification purposes only.