Friends don't let friends export to CSV

Why CSV remains dominant

  • Universally supported: almost every business tool, database, and language can import/export CSV, often with no extra libraries.
  • Works for non-technical users: people know “export/import CSV” and “open in Excel/Sheets”; many workflows, FOIA responses, and legacy systems are built around it.
  • Easy to eyeball and hand-edit for small or medium files. This is critical for debugging integrations and “one broken file” incidents.
  • For modest data sizes (MBs to low GBs), performance is usually good enough, especially when zipped.

Practical problems with CSV

  • Underspecified “family” of formats: different delimiters (,, ;, \t, |), quoting rules, header presence, encodings (UTF‑8 vs legacy), decimal separators, date formats, and null representations.
  • Real‑world files often violate RFC 4180: inconsistent quoting, wrong escaping, comments, misaligned rows, nested CSV in fields. A single robust parser for “all CSVs” is effectively impossible.
  • Locale and Excel issues: Excel changes separator based on locale, guesses types, converts IDs to numbers/dates/scientific notation, strips leading zeros, and can silently corrupt data on save. LibreOffice is often reported as more sane.
  • Encoding and schema are out‑of‑band; consumers must guess types and formats, leading to subtle bugs.

Debate over “human readable”

  • Pro: Human readability is seen as a major virtue. You can inspect, diff, and surgically fix data without code. CSV is considered durable and future‑proof.
  • Con: Human readability encourages ad‑hoc, buggy producers (“just join with commas”), making interoperability worse. Some argue binary + good tools beats text + misuse.

Parquet and other alternatives

  • Parquet praised for data pipelines: columnar, typed, schema‑aware, efficient for large datasets and partial reads; compresses well (comparable to csv.gz).
  • Criticisms: more complex spec, spotty or painful library support in some languages/environments, version quirks, not directly usable in Excel, and not ideal for row‑streaming use cases.
  • Other suggested formats: SQLite files, Arrow, Avro, Protobuf/Cap’n Proto, JSON/NDJSON, TSV, XML with schema, CSVY (CSV + YAML metadata), and “Unicode/ASCII separated values” using dedicated delimiter characters.

When CSV is appropriate vs not

  • Widely agreed:
    • Keep CSV (or XLSX) for external stakeholders and ad‑hoc analysis in spreadsheets.
    • Consider Parquet/SQLite/Arrow/etc. for internal, large, or performance‑sensitive pipelines where you control both ends.
  • Core tension: CSV is technically fragile but socially entrenched. Many see replacing it at scale as unrealistic; others argue we should at least stop using it as the default for “serious” system‑to‑system integration.