The catalog's pointer is the single source of truth. A reader resolves it once, at planning time, and then reads only the files of that snapshot; a commit mid-query affects only later readers, and the files stay because commits never delete any. That is snapshot isolation, PostgreSQL 1,289 's MVCC guarantee (Latency and Concurrency) built from immutable files. Any engine that speaks the protocol sees the same state, here DuckDB 61,228 :
-- A second engine, DuckDB, asks the same REST catalog for the books table's current state.
SET TimeZone = 'UTC';
CREATE SECRET (TYPE s3, KEY_ID 'booknest-admin', SECRET 'booknest-secret-2026',
ENDPOINT 'localhost:31900', URL_STYLE 'path', USE_SSL false, REGION 'us-east-1');
ATTACH 'warehouse' AS lake (TYPE iceberg, ENDPOINT 'http://localhost:31181',
AUTHORIZATION_TYPE 'none');
SELECT book_id, title, price FROM lake.booknest.books WHERE book_id = 1;Output
... │ 1 │ The Quiet Harbor │ 12.99 │ └─────────┴──────────────────┴──────────────┘
So: every writer commits through the same catalog, nobody deletes table files by hand (Iceberg in Production does it safely), and snapshots outlive the longest job that might read them.