That said, knowing what I know now, I would've never done that. ;-)
If SQLite is cheap to use because it's a single file, well, a sudo apt-get install PostgreSQL and then a few commands to set up the database and user password won't take you longer than 10 minutes. That's what I am arguing. There is no reason why we would use SQLite for heavy loading application such as logging. And I think we can now agree that's indeed true and I think we should promote people to use production-ready DBMS even during dev and testing, because those are the one you are going to use in production :)
Installing PostgreSQL as you described is not "good enough". If you're going to bother with that, you need to understand the database enough to tune it properly, setup backups, test restores, etc. There are more considerations than simply installing it from apt-get and then forgetting about it.
* 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
TL;DR - graphite devs don't understand postgresql, graphite user misdiagnoses the problem and blames sqlite for it.
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.
Yes there is. Small storage for a local app? SQLite is ideal.
Localstorage and app in desktop and mobile are definitely arguable.