A snapshot retention policy controls which Iceberg table snapshots remain available and when older history expires. Each commit creates a snapshot; unmanaged growth can inflate metadata, slow query planning, and strain catalog performance. section 10.3.1 section 2.4
Tune retention against workload behavior and recovery requirements:
- Use time-based windows for high-frequency ingestion, CDC, or streaming tables; a fixed retain_last count may represent only minutes or hours. section 10.3.1
- Use snapshot tags to preserve audit points, backfill states, or controlled rollback targets while pruning routine history aggressively. section 10.3.1
- Balance metadata and storage savings against reduced time-travel coverage; retention cannot recover expired historical states. section 10.3.1 section 2.4
Expiring snapshots
CALL catalog_name.system.expire_snapshots(table =>'db.sales', older_than =>TIMESTAMP '2024-06-01 00:00:00.000', retain_last =>20); section 10.3.1
Figure 10.9 When Snapshot 1 expires, only metadata or data files that aren’t associated with the remaining snapshots are deleted.
Shows that expiration removes only metadata or data files no longer associated with remaining snapshots. section 10.3.1
