Well yeah, that's kind of my point though.

We programmers get stuck into thinking that openness, speed, or other performance characteristics matter. But CSVs prove otherwise.

The reason why CSVs win in many situations is

1. Because they're convenient to edit.

2. Because they work in Microsoft Excel

CSVs have a myriad of issues: too many to list. But that doesn't matter, because convenience + Excel compatibility are king in practice.

To muse about other benefits is ignoring the core reason why CSV is used.

Exactly. Worst case a CSV can be edited and viewed or even created in MS Notepad or any other text editor which is pretty much guaranteed to be on a system. Something to deal with Sqlite? No such luck and the barrier is much higher.

> Worst case a CSV can be edited and viewed or even created in MS Notepad or any other text editor which is pretty much guaranteed to be on a system.

Good luck getting that garbage to be ingestible by anything. Odds are the system you're trying you shove it in will start by choking on the UTF8 BOM notepad insists on, then it will choke on the record separators, then on the incorrect escaping (or quoting).

> Something to deal with Sqlite? No such luck and the barrier is much higher.

SQLite is already present in most if not all environments (usually multiple times too, you have at least one instance of sqlite per browser on your machine, and probably a system one as well, and a few others), so it's really at most a matter of providing SQLite clients by default.

SQLite is not the answer. At all.

If you have this problem, maybe you just need to go to https://sqlitebrowser.org/