Topic

Data Versioning

Techniques for tracking and managing changes to datasets stored in object storage over time, including snapshots, branching, and rollback.

6 connections 3 resources

Summary

What it is

Techniques for tracking and managing changes to datasets stored in object storage over time, including snapshots, branching, and rollback.

Where it fits

S3 objects are immutable once written. Data versioning adds the concept of change history on top of that immutability — from S3's built-in object versioning to table format snapshots to Git-like branching with lakeFS.

Misconceptions / Traps
  • S3 object versioning and dataset versioning are different things. S3 versioning tracks individual object changes; dataset versioning (Iceberg snapshots, lakeFS branches) tracks logical dataset state.
  • Versioning has storage cost implications. Every snapshot or version retains data, and garbage collection policies are essential at scale.
Key Connections
  • scoped_to Object Storage, S3 — versioning operates on S3-stored data

Definition

What it is

Techniques for tracking and managing changes to datasets stored in object storage over time, including snapshots, branching, and rollback.

Why it exists

S3 objects are immutable once written. Representing logical change over time — schema evolution, data corrections, reprocessing — requires explicit versioning mechanisms built on top of the storage layer.

Recent developments

Latest signals
  • Iceberg branches and tags are the 2026 native pattern. Iceberg's branching and tagging extends time-travel into Git-like versioning: branches enable experimentation, tags preserve "golden datasets" for model lineage / auditing / retraining. Per LakeFS — What is Iceberg Versioning.
  • Project Nessie is the only catalog with Git-level version control over metadata. Brings Git-style branches + tags + commit history to data lakes; layered on top of Iceberg gives cross-table atomic commits. Per Dremio — Lakehouse Versioning: Nessie vs Iceberg vs LakeFS.
  • ML reproducibility use case: train models on precise snapshots. Iceberg versioning enables teams to train + compare models on exactly the same dataset state — pinned branches + tags become the model-lineage substrate. Per LakeFS — What is Iceberg Versioning.
  • Limitation: Iceberg versions tables, not environments. Iceberg alone versions only the tables — not the full compute environment (Python deps, model code, hyperparameters) needed for end-to-end ML reproducibility. Pair Iceberg branching with code-versioning (Git) + environment-versioning (containers) for complete reproducibility. Per arXiv 2602.02335 — Building a Correct-by-Design Lakehouse.
  • Validation-before-merge workflow. Iceberg branches let teams validate transformations, partition changes, or pipeline upgrades in isolation by running the same workloads on a branch, checking correctness, and merging only when results are safe. Per Alex Merced — Apache Iceberg Git-Like Catalog Versioning.

Connections 6

Outbound 2
Inbound 4

Resources 3