CSV vs Parquet: Which Should You Use?

CSV: plain text, no types, read top to bottom

A CSV file is text. Every value — a number, a date, a boolean — is stored as its text representation, and nothing in the file itself says what type a column is; a reader has to guess from the values (or be told). There's no index and no per-column metadata, so answering “how many rows are there?” means reading the whole file. This is also CSV's strength: it's universally readable, trivially inspectable in a text editor, and has no library dependency to write.

Parquet: typed, columnar, and self-describing

Parquet stores real types (integers, floats, dates, nested structs and lists — not just text), groups data by column rather than by row, and writes per-column statistics and row-group metadata into the file's own footer. That difference is not cosmetic: a query that only needs three of your forty columns only has to read those three columns' bytes off disk, and a query like COUNT(*) can often be answered straight from the footer's metadata without touching the actual data at all.

Real numbers, not estimates

The same 3.04 million rows of synthetic tabular data measured on this site's own infrastructure: 105 MB as CSV versus 34 MB as Parquet — roughly a third of the size, from Parquet's columnar compression alone, with no changes to the data itself. Row-count queries answered from Parquet's own row-group metadata stayed at 2.6–5.8 seconds regardless of whether the file held 3.04 million or 46.5 million rows, something a CSV reader cannot do without scanning every row.

Nested data: where CSV genuinely can't compete

A CSV cell is a scalar string. Parquet has native STRUCT (nested object) and LIST (array) column types, so a record with a nested address or a list of tags is stored as-is, not flattened into extra columns or serialized as a JSON string inside a cell. If your data has real structure, only one of these formats can actually represent it.

When to use which

• CSV for interchange with tools that expect it (spreadsheets, many APIs and legacy systems), for small files, or when a human needs to read the raw file.
• Parquet for anything analytical: larger files, repeated querying, nested data, or when file size and query speed actually matter.

Converting between them costs nothing but a bit of time: open a CSV in the CSV Viewer to confirm its schema, or inspect a Parquet file's real structure — including its row groups and per-column compression — in the Parquet Viewer.