Parquet vs Avro vs ORC: Choosing a File Format in 2026

Parquet and ORC are columnar and built for reading. Avro is row-oriented and built for writing and for schemas that change. Most analytical tables should be Parquet, most streaming and message payloads should be Avro, and ORC is mainly a question of what your existing Hive estate already uses.

That is the short answer, and for a lot of teams it is the whole answer. The useful part is knowing why, because the reasoning tells you when the default is wrong.

Row Against Column, Which Is the Real Split

Parquet and ORC store values column by column. Avro stores them record by record. Everything else follows.

Reading a few columns from many rows favours columnar. A query touching 3 of 200 columns reads 3 columns worth of bytes. The same query against a row format reads every column of every row and discards 197 of them.

Writing or reading a whole record favours row. Appending one record to a row format is appending bytes. Appending one record to a columnar format means touching every column's buffer, which is why columnar writers batch into row groups and why they are poor at small frequent appends.

Compression favours columnar, substantially. Values in a column share a type and usually a narrow range, which is ideal for dictionary, run-length and delta encoding. A row mixes a timestamp, a string and three integers, and no encoding does much with that.

The Three Formats in Practice

Apache Parquet

Columnar, created at Twitter and Cloudera, now the default file format across the lakehouse ecosystem. Rich encodings, per-column compression codecs, statistics in the footer and an optional page index for fine-grained skipping.

Choose it for analytical tables, which is nearly always. It is the default for Iceberg, Delta Lake and Hudi, and support is effectively universal.

Apache ORC

Columnar, created for Hive, and genuinely good at what it does. Stripes rather than row groups, built-in lightweight indexes, and bloom filters that Parquet only gained later. ACID support in Hive was built around it.

Choose it when you already run a Hive estate on ORC and the migration cost is not worth paying, or when your engine is measurably better at ORC than Parquet. On a new lakehouse, Parquet's ecosystem advantage usually decides it.

Apache Avro

Row-oriented, with the schema stored alongside the data as JSON. Compact binary encoding, strong and well-specified schema evolution rules, and a natural fit for message payloads.

Choose it for streaming and event data, for anything flowing through Kafka with a schema registry, and for write-heavy landing zones where records arrive one at a time.

Schema Evolution Is Where Avro Earns Its Place

This is the capability people most often overlook, and the reason Avro persists in ecosystems that are otherwise entirely columnar.

Avro carries a full schema with the data and defines explicit resolution rules between a writer's schema and a reader's schema. A reader using an older schema can read data written with a newer one, and a reader using a newer schema can read older data, as long as the changes follow the compatibility rules. Defaults make added fields safe in both directions.

That is what makes a schema registry work. Producers and consumers deploy independently, versions drift, and the data keeps being readable.

Columnar formats handle schema change far less gracefully on their own, which is exactly the gap a table format fills. Iceberg tracks columns by assigned field ID in its own metadata, so renaming a column is a metadata edit and the Parquet files underneath never change. That division of labour is worth understanding before concluding that Parquet cannot evolve.

The Comparison Table

                      Parquet           ORC               Avro
Layout                columnar          columnar          row
Built for             reads             reads             writes, exchange
Compression           very good         very good         moderate
Column pruning        yes               yes               no
Predicate pushdown    footer + page idx stripe + index    no
Bloom filters         optional          built in          no
Schema with data      yes, Thrift       yes               yes, JSON
Schema evolution      limited alone     limited alone     strong, rule-based
Small appends         poor              poor              good
Splittable            yes               yes               yes
Human readable        no                no                no, schema is
Ecosystem reach       widest            Hive-centric      streaming-centric

The Thing Almost Nobody Mentions

An Apache Iceberg table uses all three, and the choices are deliberate.

• Data files are usually Parquet, sometimes ORC or Avro. This is configurable per table.
• Manifest files and manifest lists are Avro. They are read whole during query planning, so there is nothing to prune by column, and a row format is the better fit. The manifest layer is Avro on every single query.
• Table metadata is JSON. Small, read once per commit, and useful to be able to open in a text editor when something has gone wrong.
• Statistics blobs are Puffin. A separate format for sketches and deletion vectors.

Four formats in one table, each chosen for an access pattern. It is a good illustration that the question is never which format is best, only which is best for a particular read pattern.

Choosing Without Overthinking It

Four questions settle nearly every case.

Is this an analytical table that will be queried by column? Parquet, unless an existing ORC estate says otherwise.

Is this a stream of events with independently deployed producers and consumers? Avro, with a schema registry.

Is this a landing zone taking small frequent writes? Avro on landing, then compacted into Parquet for the query layer. Keeping raw arrivals in a write-friendly format and serving from a read-friendly one is a normal and sensible split.

Are you already on ORC and everything works? Stay. The migration is real work and the performance difference on a modern engine rarely justifies it on its own.

Where Teams Go Wrong

Using Avro for the query layer

It happens when a streaming pipeline lands Avro and nobody converts it. Queries read every column of every record forever. Compaction into Parquet is usually the single largest easy win available on such a pipeline.

Using Parquet as a message format

Writing one Parquet file per message produces files with more footer than content, and a reader pays a seek and a metadata parse for each. Parquet wants batches.

Choosing on compression ratio alone

Parquet usually wins that benchmark, but if the workload reads whole records one at a time the ratio is irrelevant and the decode cost is not.

Assuming ORC is legacy

It is actively maintained and strong at what it does. The argument for Parquet is ecosystem reach, not technical superiority on every axis.

The Practical Default

Parquet for tables, Avro for streams, ORC if you are already there. Then let a table format handle the things no file format handles well on its own: atomic commits, history and schema evolution across a set of files.

If you want the layer below this comparison, the Parquet guide covers the format itself, and the file internals cover what the bytes are doing.

Frequently Asked Questions

Is Parquet always better than Avro?

No. Parquet is better for analytical reads that touch a few columns across many rows. Avro is better for writing records one at a time, for message payloads, and for schemas that change independently on the producer and consumer side.

Should I use ORC or Parquet for a new lakehouse?

Parquet, in nearly every case. ORC is technically strong, but Parquet has wider engine, language and cloud support, and it is the default for Iceberg, Delta Lake and Hudi. ORC makes sense when you already have a large Hive estate using it.

Why does Apache Iceberg use Avro for manifests?

Manifests are read whole during query planning, so there is no column to prune and no benefit from a columnar layout. A compact row-oriented format with an embedded schema suits that access pattern better.

Can I mix formats in one Iceberg table?

Iceberg supports Parquet, ORC and Avro data files, and the format is set per table through a table property. Mixing formats within a single table is possible but rarely worth the operational complexity.

Does Avro support column pruning?

No. Avro is row-oriented, so reading one field means reading every record that contains it. That is the central trade-off against Parquet and ORC.

What about JSON and CSV?

Fine as interchange, poor as storage. Both are uncompressed text with no statistics, no column pruning and no type safety. Converting them to Parquet on landing is one of the cheapest performance improvements available.

Which format compresses best?

Parquet and ORC are close and both beat Avro substantially, because storing values of one type together lets dictionary, run-length and delta encoding work before a compression codec even runs. Avro compresses a mixture of types per record, which limits what any codec can find.

Keep learning

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.