What is the difference between a file format like Parquet and a table format like Iceberg?

## Two layers, two jobs Every lakehouse table is built from two independent layers. The bottom layer is the **data-file layer**: a set of immutable files in object storage or HDFS, normally Parquet, sometimes ORC or Avro. Each file is self-describing — it carries its own schema and its own encoded, compressed data — and once written it is never edited in place. The top layer is the **table layer**: metadata written by a table format such as Apache Iceberg, Delta Lake or Apache Hudi. It records which data files constitute the table at each version, what the table's current schema and partitioning are, and what each commit added or removed. ## What the file format owns A file format decides how one file stores data: how columns are laid out and encoded, which compression codec is used, how the file records its own schema, and how it can be split so several tasks read different chunks in parallel. It also stores statistics about its own contents so a reader can skip parts of the file. What a file cannot know is everything *about the table*: whether sibling files exist, whether it is still part of the current version of the table, whether some of its rows have since been logically deleted, or what the table looked like yesterday. A file is a box of rows; it has no opinion about the collection it belongs to. ## What the table layer adds On top of that file set, a table format supplies: - **An authoritative file list per version.** Readers resolve the file set from metadata instead of listing a directory. - **Atomic commits.** Adding new files and removing replaced ones happens as one version bump, so a reader never sees half a job's output. - **Snapshot isolation and time travel.** Because old versions still reference the files they used, a query can read a consistent past state. - **Schema and partition evolution.** The table's schema lives in metadata, so a column can be added, renamed or dropped without rewriting existing files. - **File-level statistics for planning.** Row counts and per-column bounds per file let the planner skip whole files before opening any of them. - **Concurrency control.** Two writers committing at once are serialized by the metadata layer rather than racing on a directory. ## Why "a folder of Parquet files" is not a table The pre-lakehouse arrangement was a Hive-style table: a metastore entry pointing at a directory, where the table's contents were simply whatever files that directory held at read time. That is fragile. A job writing a hundred files makes its partial output visible file by file. A rewrite deletes files a running query is still reading. Listing millions of objects is slow and expensive. Nothing enforces that all the files agree on a schema. The table layer exists precisely to replace "whatever is in the folder" with "exactly this list of files, as of this version". ## Choosing a format for each layer The layers are chosen separately. Parquet and ORC are columnar and suit analytical scans that touch a few columns of very many rows. Avro is row-oriented and suits write-heavy, whole-row, append-style workloads. Iceberg can store data files as Parquet, ORC or Avro; Delta Lake's data files are Parquet. So "we use Parquet" and "we use Iceberg" are not competing statements — the usual answer is both. ## The confusion to avoid The classic interview stumble is treating a table format as a replacement for Parquet, or calling Iceberg "a file format". It is not one, and it does not re-encode your bytes. It writes metadata that points at the Parquet files you already have. That is also why adopting a table format over an existing lake can often be done without rewriting the data at all: only the table layer is new. ## How to say it in an interview "Parquet describes one file. Iceberg or Delta describe the table those files belong to — the file list, the schema, the version history, and the atomic commit that moves the table from one file set to the next." Everything else in the lakehouse — time travel, partition evolution, safe concurrent writes, compaction — is a consequence of that split.