Explain the internal working of Iceberg's snapshot isolation mechanism?

Snapshot isolation in Iceberg comes from the combination of immutable snapshots and atomic catalog pointer swaps: a reader that begins a query captures the current snapshot at that moment and continues reading against exactly that snapshot's manifest list and files for the entire duration of the query, regardless of what writers do concurrently afterward.

Because the reader resolved a specific snapshot at query start and that snapshot's referenced files never change (immutability), the reader is completely shielded from concurrent writes: even if a writer commits an entirely new snapshot midway through the reader's query, the reader keeps consistently reading the older snapshot's fixed, unchanging view until its query finishes.

This is what lets Iceberg support concurrent readers and writers without either needing to block the other: a writer's commit is a single atomic pointer swap at the catalog level, and readers already in flight simply never observe that swap until they start a new query and re-resolve the current snapshot, which is a fundamentally different (and generally simpler) consistency model than lock-based approaches that block readers and writers from operating simultaneously.