Database Branching for PostgreSQL on Kubernetes

The Branching Plugin (plugin-branching) adds database branching to OpenEverest and the Solanica Platform. A branch is a writable copy of a database, as of now, that shares its data with the source until either side writes. It's made in milliseconds to seconds, whatever the size of the database.

Use branches to develop against production-like data, test a migration, give each CI job or AI agent its own database, debug an incident without touching production, or give a preview environment a database of its own.

Early access

The Branching Plugin is at an early stage and available in early access. It isn't open source. Contact us to try it on your clusters.

The Branches tab on the instance page: branches, restore points and recent operations.

What you get

• Branches in milliseconds. A branch of a 10 GB PostgreSQL database is ready in about 0.13 seconds on XFS, with zero extra bytes. Ten at once are ready in under 7 seconds.
• Two kinds of branch. A database branch is a new database in the same server. An instance branch is a new PostgreSQL instance of its own, started from a snapshot of the source's volume. See Branch methods.
• The rest of the loop. Reset a branch to a fresh copy of its source, take a restore point before a risky change, roll back to it, and promote a branch so the source gets its data. See Reset, restore points, rollback and promote.
• Kubernetes-native. Branches, restore points and operations are custom resources (Branch, RestorePoint, Operation). Use the Branches tab, the HTTP API, kubectl or GitOps; they all work on the same objects. See the custom resource reference.
• Least privilege. The plugin never uses the database superuser or the application's credentials, and checks every UI and API request against OpenEverest RBAC as the user who made it.

Two kinds of branch

	Database branch (method: Clone)	Instance branch (method: Snapshot)
A branch is	a new database in the same PostgreSQL server	a new single-node Instance
Made with	PostgreSQL 18 file_copy_method = clone on a file system with reflinks	a CSI VolumeSnapshot of the source's volume (a standby's when there is one)
Ready in	~0.1 s on XFS, whatever the size	~25 s, whatever the size
Shares with the source	CPU, memory, connections, roles	nothing but the snapshotted data
Credentials	the source's: only the database name changes	its own
Effect on the source	the source database's sessions are disconnected for the copy	none on the primary
Best for	agent tasks, CI jobs, hundreds of short-lived copies	preview environments, load tests, branching a busy production database

In short: database branches for volume and speed, instance branches for isolation.

How it works

The plugin is one Go binary in one Deployment:

• The API serves the Branches tab through everest-server. It authorizes each request against the Everest API with the caller's token, then creates, lists or deletes the plugin's custom resources. It never changes a database itself.
• The controller reconciles Branch, RestorePoint and Operation resources. It picks an engine for the instance's provider and the branch's method, makes the branch, and reports progress in the status.
• The frontend bundle adds the Branches tab to the instance page.

Because the API only creates resources, a branch made from the UI and one applied with kubectl behave the same.

Supported databases

OpenEverest provider	Methods
provider-cloudnative-pg (PostgreSQL)	Clone: PostgreSQL 18+, CloudNativePG 1.30+. Snapshot: PostgreSQL 15+, storage with a VolumeSnapshotClass
provider-mariadb (MariaDB)	Snapshot, for standalone, replication and Galera instances. MariaDB has no in-server database copy, so no Clone
provider-mssql (SQL Server)	Snapshot, for standalone and Availability Group instances. Reset for every branch; restore points and rollback for standalone instances; no promote yet. See SQL Server instance branches

A third method, Backup, which restores a branch from a backup on storage without copy-on-write snapshots, is planned.

Use cases

• AI agent sandboxes. Each agent task gets a database branch. The agent can break it freely and reset it in under a second.
• Many agents, one winner. Several agents try different indexes or query rewrites on their own branches. Benchmark them and promote the best.
• CI. Each job gets a database with real data and no fixture loading.
• Preview environments. Each pull request gets an instance branch with its own endpoint, deleted when the pull request closes.
• Migration rehearsals. See how long a migration takes, and what it locks, on production-sized data.
• Incident debugging. Branch production as of now with an instance branch and dig in without touching it.

A quick example

apiVersion: plugin-branching.plugins.openeverest.io/v1alpha1
kind: Branch
metadata:
  name: agent-19
  namespace: team-a
spec:
  instanceRef:
    name: orders            # the PostgreSQL instance to branch
  source:
    database: app
  database: app_agent_19    # the branch, ready in milliseconds

kubectl apply -f branch.yaml
kubectl -n team-a get branches

NAME       INSTANCE   METHOD   SOURCE   DATABASE       BRANCH INSTANCE   PHASE   DURATION   AGE
agent-19   orders     Clone    app      app_agent_19                     Ready   131ms      2s

Connect to app_agent_19 with the credentials of app. Delete the Branch to drop the database.

Where to next

• Branch methods: database branches and instance branches in detail.
• Storage requirements: what makes branches instant.
• Reset, restore points, rollback and promote.
• Custom resource reference: Branch, RestorePoint, Operation.
• HTTP API reference and permissions.
• Installation.