A snapshot is a consistent, versioned representation of an Iceberg table, including the metadata and data files that constitute that state. Each write creates a new snapshot without modifying existing data files, enabling atomic commits, time travel, and concurrent-write isolation. section 6.3 section 11.3.4
Snapshots form a parent-to-child lineage rather than a guaranteed chronological log. Each records the table’s metadata state, referenced files, operation type, and summary statistics; its timestamp is user provided and should not be treated as perfectly reliable ordering. section 11.2.1
Snapshots support several operational workflows:
- Query historical table states for validation, auditing, comparisons, and historical analysis without duplicating datasets. section 2.6.3 section 11.3.4
- Rollback the current metadata pointer to a previous snapshot after bad writes, accidental deletions, or unintended schema changes. section 11.3.4
- Inspect snapshot and manifest metadata to identify changed files, investigate row-count anomalies, and trigger maintenance based on fragmentation. section 11.2.1 section 11.1.2
- Correlate table versions with external lineage and governance systems, while recognizing that Iceberg metadata alone is not a complete audit system. section 11.2.7
Investigating an unexpected row-count change
Query the table’s snapshots metadata table, order recent commits by committed_at, and compare operation summaries. An overwrite showing removed and added records can identify the suspected commit; manifests can then reveal the exact files involved. section 11.2.1
Figure 2.5 Engines can scan older snapshots to get a different list of files and then scan older versions of the data.
Shows how selecting an older snapshot changes the data-file listing scanned by an engine, making time travel concrete. section 2.6.3
