Namespace Branching

Branching creates an instant, copy-on-write clone of a namespace via branch_from.

• Constant-time regardless of namespace size
• Fully independent — reads, writes, queries, and deletes on either namespace don't affect the other
• Branch from branches — multi-level workflows like per-developer branches from staging
• Unlimited — no limit on child branches per namespace (A→B, A→C, A→D, ...) nor on length of branch chains (A→B, B→C, C→D, ...)

Pricing

Branching is billed at a flat rate of $0.032.

Storage of a branched namespace is billed on logical bytes at standard rates — each branch is billed as if it were an independent namespace. We plan to reduce this once we've observed branching in production and learned what the reuse rates are.

When to use branching vs copy_from_namespace

Use copy_from_namespace when you need a backup with full data isolation (branching shares underlying storage), when copying across regions or organizations (see the cross-region backups guide), or when re-encrypting a namespace with a different CMEK key.

Use branching otherwise.

Use cases

• Codebase indexing. Embed a codebase once; branch per local checkout so only changed files need re-indexing.
• Test pipelines. Branch a production namespace, run tests against real data, tear it down when done.
• Development environments. Give each developer a sandbox of a shared dataset.
• Snapshots. Capture the state of a changing namespace at a point in time, query the immutable snapshot many times, discard when finished.

Deleting branches

Both the source and branched namespaces are fully independent after creation. Deleting a branch does not affect the source namespace, and deleting the source does not affect any branches. Use the standard delete namespace endpoint to remove either one.

Example