Your team already writes compressed Parquet files to object storage and queries them with a SQL engine. An engineer proposes moving the same files to Iceberg. The bytes on disk barely change, so what does the table format actually add?

The mechanism

Parquet describes one file. It knows its own columns, its row groups and its per-column statistics, and nothing at all about the other 40,000 files that make up the table.

Everything a table needs beyond that has to come from somewhere. Without a table format it comes from the directory listing: the engine lists prefixes in object storage, guesses the partitioning from the path (/dt=2026-09-01/), and reads whatever is there right now.

A table format writes that missing knowledge down. The table becomes a pointer to a metadata file that names exactly which data files are in the table at that moment, with per-file statistics. Three consequences follow, and they are the whole reason to adopt one.

What you get that Parquet alone cannot give

• Atomic commits. A writer stages new files and then swaps the table pointer in one operation. Readers see the old set or the new set, never a half-written mix. With bare files a reader mid-write sees a partial table and no error is raised, because there is nothing that knows what "complete" means.
• Planning without listing. Query planning reads the manifests, so pruning uses per-file min/max statistics rather than the path. Listing a million-object prefix takes tens of seconds and costs per request; reading one manifest does not. This is usually the first effect anyone notices.
• Row-level delete and update. DELETE FROM orders WHERE customer_id = ? is expressible, because the format defines how a delete is recorded. On bare Parquet the only honest implementation is rewriting every affected file by hand.
• Schema and partition evolution. Columns are tracked by id, so a rename is metadata. Changing the partitioning does not require rewriting history.
• Time travel, because old metadata files still describe old file sets.

When plain Parquet is still the right answer

Append-only, one writer, no deletes, and small enough that listing is not the bottleneck. A daily export of a few hundred files read by one BI tool gains nothing from a table format and now needs a catalogue, maintenance jobs and a team that understands snapshots.

The honest threshold is behavioural, not a size: adopt a table format when two writers touch the same table, when a regulator or a customer can require deletion of specific rows, or when planning time is dominated by object listing. Any one of those flips it. None of them is "we have a lot of data".

Common weak answers

• "It makes queries faster." Not by itself. The same engine reads the same Parquet at the same speed; what changes is how much of it gets read and how long planning takes.
• "It gives us ACID." True but too vague to act on. Say which anomaly disappears: the partially visible write, and the lost update when two jobs write the same partition.
• "We need it because we are on a lakehouse." The word is not a requirement. The deletion obligation and the second writer are requirements.