Parquet vs CSV vs JSON: Performance, Storage, and Cloud Cost Benchmark
An empirical benchmark comparing file size compression, query execution speed, memory footprint, and cloud storage costs across Parquet, CSV, and JSON.
Benchmark Setup & Methodology
To evaluate real-world performance differences, we generated an e-commerce transactions dataset containing 10,000,000 rows across 12 diverse columns (UUIDs, timestamps, customer IDs, categorical countries, numeric prices, and status enums).
We benchmarked the exact same dataset across four popular storage representations: uncompressed CSV, uncompressed JSON Lines, Parquet with Snappy compression, and Parquet with Zstandard (Zstd) compression.
Storage Footprint Comparison
The storage reduction achieved by Parquet is staggering. By combining columnar alignment with dictionary encoding and Zstandard compression, the 10-million-row dataset shrank from 1,240 MB to just 142 MB: an 88.5% reduction in physical disk space.
| Format | File Size (MB) | Relative Size | Disk Savings |
|---|---|---|---|
| JSON Lines (.jsonl) | 1,890 MB | 152% | 0% (Baseline worst) |
| Comma-Separated (.csv) | 1,240 MB | 100% | Baseline (0%) |
| Parquet (Snappy) | 215 MB | 17.3% | 82.7% Savings |
| Parquet (Zstd Level 3) | 142 MB | 11.5% | 88.5% Savings |
Query Execution Speed & AWS S3 Cloud Costs
In cloud environments such as Amazon Athena, Google BigQuery, or Snowflake, query costs are directly pegged to the number of bytes scanned from object storage (e.g., $5.00 per Terabyte scanned on AWS Athena).
When running an analytical aggregation query ("SELECT country, SUM(price) FROM transactions GROUP BY country"):
• Querying CSV scanned all 1,240 MB across the network, taking 3.82 seconds.
• Querying Parquet with column pruning scanned only the two referenced columns (totaling 28 MB), completing in 0.19 seconds.
This translates directly into a 97.7% reduction in cloud compute bills and a 20x speedup in dashboard response times.
When Should You Still Use CSV or JSON?
Despite Parquet's overwhelming analytical dominance, text formats remain relevant in specific engineering contexts:
• Use CSV when exchanging small, human-readable data configuration files (< 5 MB) that business users must open directly in standard desktop software.
• Use JSON when communicating over public REST APIs, WebSockets, or webhook payloads where interoperability with arbitrary web clients takes precedence over storage efficiency.
• Use Parquet for any dataset over 10 MB destined for analytical queries, data warehousing, machine learning feature stores, or long-term cold archival.
Frequently Asked Questions
Is Snappy or Zstandard better for Apache Parquet?
Snappy is the default for most big data engines because it prioritizes blazing-fast decompression speeds with moderate compression. Zstandard (Zstd) yields significantly better compression ratios (saving an extra 20-30% disk space) and is recommended for modern data lakes.
How does TableView.dev achieve high speed on large Parquet files?
TableView utilizes DuckDB-Wasm which reads Parquet metadata to stream and render only visible columns and rows, avoiding loading full gigabyte datasets into memory.