Branching and Tagging
Branches and tags are named references to snapshots. They make snapshot history easier to manage for audit, experiments, validation, and release workflows.
Branches vs Tags
Branch
- Mutable reference to the head of a snapshot lineage.
- Can receive new commits.
- Useful for audit, backfills, experiments, and validation.
Tag
- Named reference to a specific snapshot.
- Usually used as a stable marker.
- Useful for releases, month-end close, audit checkpoints, and reproducible training datasets.
Create a Branch
ALTER TABLE prod.db.orders
CREATE BRANCH audit_branch;
Create a branch at a specific snapshot:
ALTER TABLE prod.db.orders
CREATE BRANCH audit_branch
AS OF VERSION 8333017788700497002;
Create a Tag
ALTER TABLE prod.db.orders
CREATE TAG release_2026_05
AS OF VERSION 8333017788700497002;
Query a Branch or Tag
SELECT *
FROM prod.db.orders
VERSION AS OF 'audit_branch';
SELECT *
FROM prod.db.orders
VERSION AS OF 'release_2026_05';
Some engines also expose branch and tag references using identifier syntax:
SELECT *
FROM prod.db.orders.`branch_audit_branch`;
Retention
Branches and tags can have retention policies. This matters because snapshot expiration can delete history that is not protected by an active reference.
Use explicit retention for:
- Regulatory snapshots.
- Published data releases.
- Long-running experiments.
- Reproducible ML training datasets.
Typical Workflows
Audit Branch
Create a branch before running validation or audit queries. The branch protects the referenced history while current table writes continue.
Release Tag
Create a tag after a successful data product release. Consumers can reproduce the exact dataset later.
Experiment Branch
Run data fixes or backfills on a branch before promoting changes to the main table workflow.
Key Takeaway
Branches and tags turn raw snapshot IDs into named data states. They are most useful when paired with clear retention rules and naming conventions.