5 ms·

In 2025, pretending that a CSV can be a reasonable alternative to a database because it is "smaller" is just wild. Totally unconscionable.

by loeber 1y ago

ncruces 1y ago
In 2020 Tailscale used a JSON file. https://tailscale.com/blog/an-unlikely-database-migration https://tailscale.com/blog/an-unlikely-database-migration
- CharlesW 1y ago
  If you continue reading, you'll see that they were forced to ditch JSON for a proper key-value database.
  - ncruces 1y ago
    I know. Now see how far JSON got them. So why wouldn't you just use a text format to persist a personal website a handful of people might use? I created one of the SQLite drivers, but why would you bring in a dependency that might not be available in a decade unless you really need it? (SQLite will be there in 2035, but maybe not the current Go drivers)
    - deepsun 1y ago
      It's self-restriction, like driving a car not using the rear view mirror. Or using "while" loops always instead of "for" loops. It's great for an extra challenge. Or for writing good literature.
      - moritzwarhier 1y ago
        You didn't really answer the dependency argument though. Until the data for a static website becomes large enough to make JSON parsing a bottleneck, where is the problem? I know, it's not generally suitable to store data for quick access of arbitrary pieces without parsing the whole file. But if you use it at build time anyway (that's how I read the argument), it's pretty likely that you never will reach this bottleneck that makes you require any DBMS. Your site is static, you don't need to serve any database requests. There is also huge overhead in powering static websites by a full-blown DBMS, in the worst case serving predictable requests without caching. So many websites are powered by MySQL while essentially being static... and there are often unnecessarily complicated layers of caching to allow that. But I'm not arguing against these layers per se (the end result is the same), it's just that, if your ecosystem is already built on JSON as data storage, it might be completely unneeded to pull in another dependency. Not the same as restricting syntax within one programming language.
    - jpc0 1y ago
      > SQLite will be there in 2035, but maybe not the current Go drivers Go binaries are statically linked, unless you expect the elf/pe format to not exist in 2035 your binary will still run just the same. And if not well there will be an SQLite driver in 2035 and other than 5 lines of init code I don’t interact with the SQLite drover but rather the SQL abstraction in golang. And if it’s such an issue then directly target the sqlite C api which will also still be there in 2035.
r0fl 1y ago
I use CSV files to run multiple sites with 40,000+ pages each. Close to 1mil pages total Super fast Can’t hack me because those CSV files are stored elsewhere and only pulled on build Free, ultra fast, no latency. Every alternative I’ve tried is slower and eventually costs money. CSV files stored on GitHub/vercel/netlify/cloudflare pages can scale to millions of rows for free if divided properly
- akudha 1y ago
  Is this a static website? If yes, what do you use to build?
- vineyardmike 1y ago
  Can't argue with what works, but... All these benefits also apply to SQLite, but SQLite is also typed, indexed, and works with tons of tools and libraries. It can even be stored as a static file on various serving options mentioned above. Even better, it can be served on a per-page basis, so you can download just the index to the client, who can query for specific chunks of the database, further reducing the bandwidth required to serve.
  - deleted 1y ago
    [deleted]
  - deepsun 1y ago
    Just to be pedantic, SQLite is not really typed. I'd call them type-hints, like in Python. Their (bad IMHO) arguments for it: https://www.sqlite.org/flextypegood.html https://www.sqlite.org/flextypegood.html
    - edmundsauto 1y ago
      Don’t you think it’s better in this dimension than CSV though? It seems to me like it’s a strictly better improvement than the other option discussed.
    - newlisp 1y ago
      https://www.sqlite.org/stricttables.html https://www.sqlite.org/stricttables.html
nullishdomain 1y ago
Not so sure about this. At scale, sure, but how many apps are out there that perform basic CRUD for a few thousand records max and don't need the various benefits and guarantees a DB provides?
- makeitdouble 1y ago
  I assume parent's dispair is about CSV's amount of traps and parsing quirks. I'd also be hard pressed to find any real reason to chose CSV over JSONL for instance. Parsing is fast and utterly standard, it's predictible and if your data is really simple JSONL files will be super simple. At it's simplest, the difference between a CSV line and a JSON array is 4 characters.
sieabahlpark 1y ago
[dead]
nickjj 1y ago
If you ignore size as a benefit, CSV files still have a lot of value: - It's plain text - It's super easy to diff - It's a natural fit for saving it in a git repo - It's searchable using standard tools (grep, etc.) - It's easy to backup and restore - You don't need to worry about it getting corrupt - There are many tools designed to read it to produce X types of outputs A few months ago I wrote my own CLI driven CSV based income and expense tracker at https://github.com/nickjj/plutus https://github.com/nickjj/plutus. It helps me do quartly taxes in a few minutes and I can get an indepth look at my finances on demand in 1 command. My computer built in 2014 can parse 100,000 CSV rows in 560ms which is already 10x more items than I really have. I also spent close to zero effort trying to optimize the script for speed. It's a zero dependency single file Python script using "human idiomatic" code. Overall I'm very pleased in the decision to use a single CSV file instead of a database.

In 2025, pretending that a CSV can be a reasonable alternative to a database because it is "smaller" is just wild. Totally unconscionable.

by loeber 1y ago

In 2025, pretending that a CSV can be a reasonable alternative to a database because it is "smaller" is just wild. Totally unconscionable.

ncruces 1y ago

In 2020 Tailscale used a JSON file. https://tailscale.com/blog/an-unlikely-database-migration https://tailscale.com/blog/an-unlikely-database-migration

CharlesW 1y ago
If you continue reading, you'll see that they were forced to ditch JSON for a proper key-value database.
- ncruces 1y ago
  I know. Now see how far JSON got them. So why wouldn't you just use a text format to persist a personal website a handful of people might use? I created one of the SQLite drivers, but why would you bring in a dependency that might not be available in a decade unless you really need it? (SQLite will be there in 2035, but maybe not the current Go drivers)
  - deepsun 1y ago
    It's self-restriction, like driving a car not using the rear view mirror. Or using "while" loops always instead of "for" loops. It's great for an extra challenge. Or for writing good literature.
    - moritzwarhier 1y ago
      You didn't really answer the dependency argument though. Until the data for a static website becomes large enough to make JSON parsing a bottleneck, where is the problem? I know, it's not generally suitable to store data for quick access of arbitrary pieces without parsing the whole file. But if you use it at build time anyway (that's how I read the argument), it's pretty likely that you never will reach this bottleneck that makes you require any DBMS. Your site is static, you don't need to serve any database requests. There is also huge overhead in powering static websites by a full-blown DBMS, in the worst case serving predictable requests without caching. So many websites are powered by MySQL while essentially being static... and there are often unnecessarily complicated layers of caching to allow that. But I'm not arguing against these layers per se (the end result is the same), it's just that, if your ecosystem is already built on JSON as data storage, it might be completely unneeded to pull in another dependency. Not the same as restricting syntax within one programming language.
  - jpc0 1y ago
    > SQLite will be there in 2035, but maybe not the current Go drivers Go binaries are statically linked, unless you expect the elf/pe format to not exist in 2035 your binary will still run just the same. And if not well there will be an SQLite driver in 2035 and other than 5 lines of init code I don’t interact with the SQLite drover but rather the SQL abstraction in golang. And if it’s such an issue then directly target the sqlite C api which will also still be there in 2035.

r0fl 1y ago

I use CSV files to run multiple sites with 40,000+ pages each. Close to 1mil pages total Super fast Can’t hack me because those CSV files are stored elsewhere and only pulled on build Free, ultra fast, no latency. Every alternative I’ve tried is slower and eventually costs money. CSV files stored on GitHub/vercel/netlify/cloudflare pages can scale to millions of rows for free if divided properly

akudha 1y ago
Is this a static website? If yes, what do you use to build?
vineyardmike 1y ago
Can't argue with what works, but... All these benefits also apply to SQLite, but SQLite is also typed, indexed, and works with tons of tools and libraries. It can even be stored as a static file on various serving options mentioned above. Even better, it can be served on a per-page basis, so you can download just the index to the client, who can query for specific chunks of the database, further reducing the bandwidth required to serve.
- deleted 1y ago
  [deleted]
- deepsun 1y ago
  Just to be pedantic, SQLite is not really typed. I'd call them type-hints, like in Python. Their (bad IMHO) arguments for it: https://www.sqlite.org/flextypegood.html https://www.sqlite.org/flextypegood.html
  - edmundsauto 1y ago
    Don’t you think it’s better in this dimension than CSV though? It seems to me like it’s a strictly better improvement than the other option discussed.
  - newlisp 1y ago
    https://www.sqlite.org/stricttables.html https://www.sqlite.org/stricttables.html

nullishdomain 1y ago

Not so sure about this. At scale, sure, but how many apps are out there that perform basic CRUD for a few thousand records max and don't need the various benefits and guarantees a DB provides?

makeitdouble 1y ago
I assume parent's dispair is about CSV's amount of traps and parsing quirks. I'd also be hard pressed to find any real reason to chose CSV over JSONL for instance. Parsing is fast and utterly standard, it's predictible and if your data is really simple JSONL files will be super simple. At it's simplest, the difference between a CSV line and a JSON array is 4 characters.

sieabahlpark 1y ago

[dead]

nickjj 1y ago

If you ignore size as a benefit, CSV files still have a lot of value: - It's plain text - It's super easy to diff - It's a natural fit for saving it in a git repo - It's searchable using standard tools (grep, etc.) - It's easy to backup and restore - You don't need to worry about it getting corrupt - There are many tools designed to read it to produce X types of outputs A few months ago I wrote my own CLI driven CSV based income and expense tracker at https://github.com/nickjj/plutus https://github.com/nickjj/plutus. It helps me do quartly taxes in a few minutes and I can get an indepth look at my finances on demand in 1 command. My computer built in 2014 can parse 100,000 CSV rows in 560ms which is already 10x more items than I really have. I also spent close to zero effort trying to optimize the script for speed. It's a zero dependency single file Python script using "human idiomatic" code. Overall I'm very pleased in the decision to use a single CSV file instead of a database.