It's not satire.

They are serious about the religious stuff.

I fail to see how that's an issue.

Also, in the very page you linked, he clarified:

In the face of today's attention, which has included a wave of aggressive responses accusing Hipp of un-Christian behavior – he tells us he updated the preface to highlight the fact that by adopting St Benedict's rules he was not seeking to exclude anyone.

"Nobody is excluded from the SQLite community due to biological category or religious creed," he told us. "The preface to the CoC should make this clear. The only way to get kicked out of the SQLite community is by shouting, flaming, and disrespectful behavior. In 18 years, only one person has ever been banned from the mailing list."

He also said that he considered only retaining the bullet points that would be relevant to the project, but ultimately decided that would be disrespectful to the original text and its author. Seems fine to me.

What admin tooling do you need? You haven't defined any problem requiring a solution.

I was just reiterating your point and agreeing with you, bud.

I'm not sure I understand your point? You can connect to and run queries/etc on the production database in SQLite.

I'm not really advocating for using SQLite by the way - I've only ever used it on smartphone apps myself where a full database wouldn't even have enough RAM to run at all. I'm just pointing out that permissions isn't a feature I've ever found useful.

For example, say I have an invoice table that is written to whenever a customer buys a product. Customers need to have write access to the table in the database. But I don't want them to be able to write anything they want - there needs to be severe restrictions on what can be written, and those have to be done outside of the database.

Since you have to do some of your permissions outside the database, it's more reliable to just do all of them there. Splitting things up with half your security in one place and half in another is asking for bugs.

The main reason I would avoid SQLite is the backup system, which essentially takes your whole database offline (for write access anyway) while the backup is running. That's just not good enough once the database reaches a size where backups take more than a moment. But if you're not storing much data, or not doing many writes, that's a non-issue.

SQLite definitely has advantages. It's often extremely fast for example. The lack of complex features removes performance bottlenecks all of the place and you can do millions of basic select queries per second in SQLite. Obviously not every query is that fast, but a lot of them are especially if you design your indexes/etc properly.

Definitely not a silver bullet, but I do think anyone who writes code that reads or writes data should be at least aware of the basic capabilities of SQLite. It's free. It's reliable. It runs literally on any platform (you can even run it client side in a webpage these days). So the only reason to avoid SQLite is if it's the wrong tool for the job. And you can't make that judgement call unless you have experience with it.

SQLite should be in every developer's toolchain, even if you don't have a use for it right now.