Apache Parquet is a file format. Apache Iceberg is a table format. They are not alternatives, they are different layers of the same stack, and an Iceberg table almost always contains Parquet files. If you are choosing between them, the question is malformed.
This comparison gets searched constantly, which tells you the naming is doing nobody any favours. Both are Apache projects. Both involve columns. Both get described as “open formats for analytics”. So people reasonably assume they compete.
They do not. The clearest way to see it is to ask what each one knows.
A Parquet file knows about itself. It knows its schema, its row groups, the encoding and compression of each column chunk, and the minimum and maximum values in each. It knows nothing about any other file. Two Parquet files sitting in the same directory have no relationship beyond happening to share a prefix.
An Iceberg table knows which files exist. It holds a list of every data file that belongs to the table right now, what each one contains, which partition it falls in, and what the table looked like at every previous commit. It knows nothing about how any individual file encodes its bytes.
That division is the whole relationship. Parquet answers “what is in this file”. Iceberg answers “which files are the table”.
Imagine a directory of 10,000 Parquet files that together make up a sales table. Every one is well encoded and internally consistent. Now answer a few ordinary questions.
Parquet cannot answer any of these, and it was never meant to. Every one of them is a question about a set of files over time, and a file format has no vocabulary for either.
Before table formats existed, the answer was a directory listing plus convention plus hope. Hive made the directory structure itself the metadata, which is why renaming a partition column was a migration and why a reader could see a partially written directory.
Iceberg sits above the files and keeps an explicit, versioned record of them.
A table is the set of files its current snapshot references, not the set of files in a directory. A file nothing references is not in the table, which is exactly why orphan files can exist at all and why a failed write cannot corrupt a table.
A write produces new files, then swaps a single pointer. Readers see the old state or the new state, never a mixture. The swap is the transaction boundary, and it is one pointer regardless of whether the commit touched one file or fifty thousand.
Every commit leaves the previous state intact and addressable. Reading the table as of last Tuesday is reading an older snapshot, not restoring a backup.
Iceberg tracks columns by assigned field ID rather than by name or position. Renaming a column changes a label in metadata, and the Parquet files underneath are untouched. Partition layout can change for future writes while old data keeps its old layout, and queries read across both.
Parquet files are immutable. Iceberg expresses a delete either by rewriting the affected files or by recording delete files that readers apply at scan time. The immutability of Parquet is preserved, and the table still behaves as though rows changed.
This is where the division of labour is most visible, and it is the part people most often conflate.
Parquet keeps statistics inside the file. Each column chunk records minimum and maximum values and a null count in the footer, and an optional page index carries per-page bounds. These let an engine skip row groups and pages within a file it has already opened. How that works is a post of its own.
Iceberg keeps statistics about files. Its manifest files record, for every data file, the partition values and the per-column bounds. These let an engine eliminate entire files before opening any of them.
The sequence on a real query runs top down. The catalog resolves the current snapshot. The manifest list eliminates whole manifests by partition range. The manifests eliminate individual files by column bounds. Only then does the engine open the surviving Parquet files, and inside each one the footer and page index eliminate row groups and pages.
Four opportunities to read less, split across two formats. Remove either layer and you lose half of them.
A directory of Parquet files queried directly by DuckDB, pandas or Spark is a perfectly reasonable thing. For a dataset one team owns, that nobody concurrently writes, where nobody needs history, a table format is machinery you do not need.
The moment two writers appear, or someone asks what the data looked like last month, or a schema has to change without a rewrite, you start rebuilding a table format by hand. That is usually the signal.
Iceberg supports Parquet, ORC and Avro for data files. Parquet is the default nearly everywhere, ORC appears in shops with Hive history, and Avro shows up for write-heavy streaming ingestion where its row orientation is an advantage.
There is a detail worth knowing here. Iceberg's own metadata is written in Avro, not Parquet. Manifest files and manifest lists are Avro because they are read whole during planning, and a row-oriented format suits that better than a columnar one. So even an all-Parquet Iceberg table is reading Avro on every query.
Apache Parquet Apache Iceberg
Layer file format table format
Scope one file a set of files over time
Written in Thrift-encoded metadata Avro manifests, JSON metadata
Unit of work row group, page snapshot, manifest, data file
Statistics column chunk, page index per-file, per-partition
Atomic writes no yes
Time travel no yes
Schema evolution limited, positional full, by field ID
Row-level delete no, files are immutable yes, rewrite or delete files
Needs a catalog no yes
Replaces the other no noFollow a single UPDATE that changes 400 rows in one partition of a ten-billion-row table, and the split becomes concrete.
Neither layer could do the other's job. Parquet has no way to express “these three files are replaced by those two”. Iceberg has no way to decide which pages inside a file are worth decoding.
If what you actually want is a choice between genuine alternatives, there are two real comparisons hiding behind this one.
Table format against table format. Iceberg, Delta Lake and Apache Hudi occupy the same layer and do compete. That is a live decision with real trade-offs around engine support, governance and ecosystem.
File format against file format. Parquet, ORC and Avro occupy the same layer and do compete. Columnar against row-oriented, read-optimised against write-optimised.
Both of those are worth arguing about. Iceberg against Parquet is not, because nothing in one overlaps the other.
Three things, and naming them usually settles the argument.
Both are columnar, so both get called a columnar format. Parquet is columnar in the literal sense that it stores values column by column. Iceberg is described that way because it is usually layered over columnar files, not because it arranges anything itself.
Benchmarks compare them. You will see “Iceberg versus Parquet” query timings, which is comparing a directory of Parquet files against an Iceberg table over Parquet files. That is a real comparison, but it measures the value of the table layer, not one format against another.
Vendors say “Iceberg format”. It is shorthand, it is everywhere, and it leaves people assuming Iceberg is a file on disk. It is not. An Iceberg table is metadata plus a catalog plus files.
If your question is about compression, encodings, row group sizing or why a scan reads more than you expected inside a file, you want Parquet.
If your question is about concurrent writers, history, schema changes, deletes, or which files belong to a table, you want Iceberg.
If your question is “which should I pick”, the answer is almost always both, in that order, with Parquet underneath.
No. Iceberg is a table format. It describes which files make up a table, their schema history and their snapshots. The data itself lives in Parquet, ORC or Avro files that Iceberg points at.
No. Iceberg tables normally contain Parquet files. Iceberg adds a layer above the files rather than replacing the format inside them.
Yes, and for a single-owner dataset with no concurrent writers and no need for history, that is often the right choice. You start needing a table format when you need atomic writes, time travel, schema evolution without rewrites, or row-level deletes.
The question does not type-check. A benchmark labelled this way is comparing a plain directory of Parquet files against an Iceberg table over Parquet files, which measures what the table layer adds, not one format against the other.
Iceberg's metadata does. Manifest files and manifest lists are Avro because they are read whole during query planning, where row orientation suits better than columnar. Data files are usually Parquet.
Both, at different granularity. Iceberg manifests hold per-file bounds that eliminate whole files before they are opened. Parquet footers and the page index hold per-row-group and per-page bounds that eliminate data inside a file that has been opened.
No. A Parquet file is self-describing and needs nothing else to be read. Iceberg does need a catalog, because something has to record which metadata file is current.
For a full treatment of the table format, download Apache Iceberg: The Definitive Guide by Tomer Shiran, Jason Hughes, and Alex Merced, free from Dremio.
To see these ideas applied in practice, explore the Dremio documentation.
Deploy agentic analytics directly on Apache Iceberg data with no pipelines and no added overhead.
Editor’s note, September 2026. This post was published in September 2023 and some product details have changed since. Nessie is still available and self-deployable under the Apache-2.0 licence, and it remains the clearest implementation of catalog-level branching. It is not an Apache Software Foundation project, and its development has slowed considerably. For how the current […]
With its capabilities in on-prem to cloud migration, data warehouse offload, data virtualization, upgrading data lakes and lakehouses, and building customer-facing analytics applications, Dremio provides the tools and functionalities to streamline operations and unlock the full potential of data assets.
Apache Iceberg 1.12.0 expands v3 engine support, REST catalog operations, streaming reliability, and v4 groundwork. Learn how to upgrade safely.