4 ms·
There are plenty of reasons. * Single file to back up * Unix fs permissions sufficient for security * Simplicity valuable over write concurrency * Abil
by mst 13y ago
There are plenty of reasons.
* Single file to back up
* Unix fs permissions sufficient for security
* Simplicity valuable over write concurrency
* Ability to write functions/aggregates/collations in the language you're embedding sqlite in
* No need for maintaining and securing a system daemon
This article isn't, at all, about a problem with SQLite. It's about graphite shipping a stupid postgres schema. Had they used text for the column like anybody who knows how to use postgres would recommend, the graph names would've transferred fine.
TL;DR - graphite devs don't understand postgresql, graphite user misdiagnoses the problem and blames sqlite for it.
- Someone 13y agoThe way I read this, this _is_ a problem with SQLite (somewhat). Both schemas limit the length of graph names, but SQLite ignores that part of the schema. One can discuss whether it is a good idea to have that arbitrary, low limit, but that is not what this is about. I agree that there are plenty of reasons to use SQLite in production. IMO, the conclusion should have been that one should run the same database in development, test, and production.
- obfuscurity_ 13y agoExcuse my french, but you're an idiot. I don't know if you simply didn't read the article, or are incapable of grasping the facts within.