Zettabranch Solution Brief

The Challenge

Modern development wants a database per unit of work — one per pull request, one per CI run, one per AI coding agent. Production Postgres does not oblige.

Copies cost what the data costs. A dump-and-restore of a terabyte takes hours and another terabyte of disk, so teams share one staging database and serialise behind it. A destructive migration, a bad seed, or a runaway agent takes the environment down for everyone — and a branch nobody has touched in a week still bills like production.

Agents make it acute. An AI agent that writes SQL needs a database it can safely destroy, on demand, dozens of times a day — in seconds, not minutes.

Hosted branching forces a trade-off. Managed services solve the workflow, but the database has to live on their infrastructure. For teams under regulatory, residency, or security constraints, that is the one thing that cannot move — leaving a choice between a modern branching workflow and keeping data where policy requires it.

AT A GLANCE

Branchable PostgreSQL in your own cloud account
Copy-on-write in the storage layer — fork any size in seconds
Idle branches park to object storage at bucket price
Seed from any Postgres with inline PII masking
Vanilla Postgres — stable URLs, nothing proprietary
Two-node active-active HA; runs on AWS, Azure, GCP

The Solution — Branching in the Storage Layer, Inside Your Account

Zettabranch deploys as one unit: MayaScale storage nodes providing an NVMe hot pool and an object-backed cold pool, a Kubernetes control plane running CloudNativePG and the ZettaLane CSI driver, and a branching API with a wake-on-query gateway and console. The database is unmodified PostgreSQL throughout, and everything runs inside your own VPC.

Developers · CI Runners · AI Agents · Analysts — one stable PostgreSQL URL per branch

PostgreSQL wirewake-on-query gatewayREST API · zettab CLI · console

↓ ↓ ↓ ↓

Branching API & gateway Per-branch connection strings · wake-on-query · inline PII masking on ingest

CloudNativePG on Kubernetes Vanilla PostgreSQL · bundled k3s or your EKS / GKE / AKS · ZettaLane CSI

MayaScale storage engine ZFS copy-on-write clones over NVMe-oF · branch time independent of size · active-active HA

Hot NVMe poolrunning & parked branches

Cold object poolevacuated branches — S3 / GCS / Blob, in place

Why Zettabranch

01

A branch per unit of work, not per team

Because a branch is a clone rather than a copy, the ceiling on environments becomes organisational, not economic. Every PR, test-matrix entry, and agent run can have its own full-size database — and forking a terabyte takes the same few seconds as an empty one.

02

Idle capacity that doesn't bill like production

Parked branches release compute; drained branches release their NVMe entirely and sit on object storage, read and written in place. A dormant branch costs bucket prices instead of premium block storage — the axis hosted branchers leave on the table.

03

Sovereignty without giving up the workflow

Data, control plane, and API run in your own account, on vanilla PostgreSQL. There is no vendor data plane in the path and nothing proprietary to migrate onto or off of — every branch is ordinary Postgres an auditor can inspect with standard tools.

Key Capabilities

Seed from your database, masked. Load from any PostgreSQL into a branch with deterministic masking applied inline; the source is untouched and PII never lands on the branch.

Instant branches at any size. Fork time is independent of data volume — the clone is milliseconds; only Postgres startup counts.

Version and fork. Tag a version, fork from it, or fork as of a point in time — no restore job.

Two-depth sleep. Idle branches park (compute off, wake ~2s); a deliberate drain evacuates them to object storage to reclaim capacity.

Wake on query. The gateway holds the connection while a branch comes up, so clients see a slow first query, not a failure.

Stable connection strings. One URL per branch, unchanged across sleep, wake, and promotion — CI jobs and agents hold a single endpoint.

Isolation that holds. A branch can be dropped, corrupted, or filled without touching its parent or production.

Scoped access. Project-scoped tokens for teams and CI; per-branch database credentials.

High availability. Two-node active-active storage with automatic failover; branches keep serving on the same URLs.

Point-in-time recovery. Scheduled recovery points with configurable retention, and fork-as-of-a-timestamp.

Drain for maintenance. Deployment-wide evacuation behind a readiness gate before a node is shut down or replaced.

Visible and scriptable. A live branch-tree console; every action is in the REST API and the single-binary zettab CLI.

Use Cases

AI coding agents

Give each agent a disposable branch of real data — it can run migrations, rewrite schemas, or drop tables, and the blast radius ends at the branch. Wake-on-query means an idle agent costs nothing to keep around.

Pull-request preview environments

Every PR gets a database seeded from the same version as production. Reviewers see real behaviour on real data shapes, and the branch disappears with the PR.

CI and integration testing

Parallel test shards each take an independent branch instead of queuing behind one shared database, and a failing run leaves its branch intact for inspection.

Regulated and sensitive-data teams

Realistic branches without moving data out of the boundary: masking is applied inline on ingest, the whole platform runs in your account, and every branch is ordinary PostgreSQL an auditor can inspect with standard tools.

Migration rehearsal & ad-hoc analytics

Fork production as of a timestamp, run the migration, measure it, throw it away — repeat until the runbook is right, with no maintenance window. Or hand an analyst a writable, masked branch instead of read-replica access.

Deploy into your own account in one command

One command provisions storage, the Kubernetes control plane, and the branching API; it prints the console URL, admin token, and Postgres gateway endpoint. The single-binary zettab CLI — suited to CI runners and agent images — drives everything.

# provision, then branch like git ./deploy-zettabranch.sh --cloud azure -g <rg> -l <region> -n mydb zettab create branch pr-1234 --from mydb-main --at v1 export DATABASE_URL="$(zettab branch url pr-1234)"

Programs & Partnerships

Deploys into your own Amazon Web Services, Microsoft Azure, or Google Cloud account, via Terraform. sales@zettalane.com

A Postgres branch for every agent, PR, and test run