Parquet vs CSV: Size, Scan and Cost

Compression is just a constant: Parquet lands somewhere between a quarter and an eighth of uncompressed CSV for the same table, depending on column cardinality. That is why the input above asks for a data profile rather than only a codec — dictionary and run-length encoding make a status column with six distinct values nearly free and do almost nothing for a column of UUIDs. The codec (Snappy / ZSTD / GZIP) then moves that by about 20% either way.

The gap that matters comes from the other two, and they multiply: querying 4 of 40 columns means a columnar reader touches only those 4 column chunks — 10x — and partition pruning that narrows the scan to 10% of the table is another 10x. CSV cannot have the first one, because a row-oriented file has to be read whole to extract one field. So the difference lands two orders of magnitude apart, not at the 4–8x that compression alone buys.

Two boundaries worth remembering. First, Athena bills a 10 MB minimum per query: on a small table, optimising down to 200 KB still costs 10 MB. That floor is in the numbers above — shrink the row count and you will watch both sides converge on the same figure. Second, row-group statistics pruning (min/max predicate pushdown) is *not* modelled, so a real Parquet query often reads even less: the Parquet side here is the conservative estimate.

Also not modelled: the small-files problem, where a few million 1 MB objects make metadata and request count dominate the bill, and Parquet's higher CPU cost on the write path.