How Parquet Won
Parquet did not win by being the most elegant format ever designed. It won by being the right answer to a specific problem at a specific time, and then becoming the default before most teams had seriously evaluated the alternatives. The problem was analytical query performance at scale. When data teams started running aggregations across hundreds of millions of rows stored in flat CSV files, the costs were obvious: you read every column to compute one, you parse text on every read, and there is no compression scheme that takes advantage of the fact that a column of integers has very different entropy characteristics from a column of free-text strings. Parquet is a columnar format, which means queries that touch a subset of columns only read the data they need. Its encoding and compression schemes — dictionary encoding, run-length encoding, bit packing — are applied per column, where they are most effective. The result is that Parquet queries on analytical workloads run faster and read less data than equivalent CSV queries, often by an order of magnitude.
Apache Hadoop popularised it, Spark cemented it, and cloud object storage made it permanent. Once Parquet became the native format for data lakes on S3 and GCS — stored cheaply, queried directly by Athena, BigQuery, Redshift Spectrum, and Databricks — the switching cost for any team already using it became enormous. New tools built Parquet support first. The ecosystem compounded.
Why CSV Never Lost
CSV is not being replaced. It is being pushed to the edges of the data stack, and those edges are larger than most data engineers want to admit. The reason CSV survives is not that people are ignorant of Parquet — it is that CSV is universally readable without any tooling. Every spreadsheet application opens it. Every database imports it. Every programming language with a standard library can parse it without a dependency. You can open it in a text editor and understand exactly what it contains. That last point matters more than it should: when something goes wrong with a data pipeline at 2 AM, the ability to inspect raw data without setting up a runtime is not a minor convenience — it is the difference between debugging in minutes and debugging in hours.
CSV also dominates data interchange with systems outside the data platform. Finance teams export CSVs. Government data portals publish CSVs. Third-party vendors deliver CSVs. The world outside the Spark cluster has not adopted Parquet, and it is not going to. As long as data has to cross organisational boundaries or reach a human who will open it in Excel, CSV remains the lowest-friction option.
The Layer Cake Model
The most useful mental model for where each format belongs is not a competition but a layered architecture. At the raw ingestion layer, you often receive data in whatever format the source system produces — frequently CSV, JSON, or XML. At the storage layer for internal analytical workloads, Parquet (or a similar columnar format like ORC or Avro for specific use cases) should be the default. At the delivery layer — reports sent to stakeholders, exports requested by downstream teams, data shared with external partners — CSV re-emerges as the practical choice.
Teams that treat this as a war miss the point. The question is never "which format is better" but "which format is appropriate for this specific data movement." Converting CSV to Parquet on ingest is a standard pipeline step, not a philosophical commitment. Converting Parquet back to CSV for a business user who needs to open the file in Excel is equally standard. The cost of the conversion is trivial. The cost of using the wrong format in the wrong context — slow queries, incompatible tooling, data that cannot be inspected, files that cannot be opened — is not.
What the Benchmarks Miss
Benchmarks comparing Parquet and CSV almost universally show Parquet winning on query performance for analytical workloads. They are also almost universally measuring the case where Parquet wins by design: large datasets, columnar aggregations, repeated reads of the same data. What they do not measure is write latency for small datasets, the overhead of schema management when your data changes frequently, the debugging friction of a binary format, or the cost of tooling compatibility failures when a Parquet file produced by one library is slightly inconsistent with what another library expects.
None of this means you should use CSV for analytical workloads. It means the benchmark does not capture the full cost of the format choice, and that "Parquet is faster" is true in a specific context that may or may not be the context you are actually operating in.
What to Actually Use
The practical answer is straightforward: use Parquet for everything stored in a data lake, data warehouse staging area, or analytical pipeline where performance and storage efficiency matter and both ends of the read/write are inside your controlled tooling environment. Use CSV for anything that needs to be human-readable, shared outside your data platform, imported from an external system, or opened by someone without access to Spark, Pandas, or DuckDB.
If you are building a new pipeline in 2026 and storing data internally, default to Parquet. If you are building a data export for a business user, default to CSV. If you are building an API that serves data to unknown consumers, consider both and let the consumer specify. The format war was never the interesting question. The interesting question is whether the people designing your pipelines understand the boundary conditions well enough to make the choice correctly rather than reflexively.