Parquet vs CSV: what you actually save, and why

"Just use Parquet" is the most repeated advice in data engineering and the least explained. It is good advice. But if you do not know why it wins, you cannot tell when it will not, and you end up either converting files that should have stayed CSV or being surprised when your ratio is 3x instead of the 20x you read about.

There are three mechanical reasons, and none of them need a paper.

1. It reads only the columns you asked for

A CSV stores a row at a time:

id,name,email,signup_date,revenue
1,Alice,[e-mail],2026-01-15,127.50
2,Bob,[e-mail],2026-01-16,340.00

To total the revenue, the reader walks the whole file. Every name, every email, every date, all read off disk and parsed to reach one column.

Parquet stores a column at a time. SELECT SUM(revenue) reads the revenue column and nothing else. Most analytical queries touch 10 to 20% of the columns, so they read 10 to 20% of the file. CSV always reads 100%.

That is the entire trick behind the headline benchmarks, and it is why the win grows as your tables get wider.

2. Similar things sit next to each other, so they compress

Compression works on patterns. A CSV row is a string, a date, a float and two integers jammed together, which is close to noise. A Parquet column is ten million floats, or ten million dates, or the word "USA" repeated ten thousand times.

Parquet picks an encoding per column with no input from you:

• Run-length encoding turns ten thousand repeats of "USA" into the pair ["USA", 10000].
• Dictionary encoding maps "San Francisco" to 0 and "New York" to 1, then stores the small integers.
• Delta encoding turns hourly timestamps [1704067200, 1704070800, 1704074400] into [1704067200, +3600, +3600].

Then a general compressor runs over the result.

This is why asking "what compression ratio will I get?" has no answer without your schema. What decides it:

Column type	Typical ratio	Why
Booleans	50-100x	Bit-packing
Timestamps	10-50x	Delta encoding
Low-cardinality strings	10-30x	Dictionary encoding
Integers, IDs, counts	5-20x	Dictionary and bit-packing
High-cardinality strings	2-5x	Little structure to exploit
Floats, measurements	2-4x	Little structure to exploit

A table of flags, IDs and timestamps compresses enormously. A table of sensor readings barely compresses at all. Both are normal.

Real numbers, so you have an anchor: ten million rows of synthetic user data go from about 635 MB of CSV to about 29 MB of Parquet, roughly 22x. Ten million NYC taxi rides go from 2.1 GB to 180 MB, roughly 12x. Event logs usually land at 15 to 25x, transactional data at 10 to 15x, float-heavy sensor data at 4 to 8x.

Measure your own. It takes one write.

---

This is the first part. The full post — including the rest of the working details — is on my site: Parquet vs CSV: what you actually save, and why