You can rm a database as well. In multiple different ways in fact. You can also put constraints on text files by forcing editing via a helper program (much like visudo and crontab do). In that regard the text format isn't much different from a database format aside the encoding of the data (it's probably also worth mentioning that you can - and some people do - store a database as flat text files if you wanted. They don't necessarily have to be binary blobs).

> "What happens when the kernel has a bug or vulnerability? There are quite a few mature db systems. Plus, all text files depend on the file-system, which is why you store root on something stable like ext (still depends on hdd drivers though, unless you have some some ramfs on boot)."

I'm not sure I get your point. What do kernel bugs have to do with text vs binary formats? Or the argument for or against centralised databases? Databases still need to store files on persistent storage so if your text files are compromised from a kernel vulnerability or instability in the file system then your binary database files will also be.

I'm not sure using a helper program has as many assurances around it, and manipulating data in a db often won't involve any 'rm' command, though copy/replacing a text file might.

> What do kernel bugs have to do with text vs binary formats?

you said "what if the db has a bug or vulnerability", my point is you have to rely on something, even the kernel. The difference is how stable these things are, and databases can be very stable.

> if your text files are compromised from a kernel vulnerability

not all kernel vulnerabilities will put the db at risk, it depends on the exposure to parts of the kernel. You can restrict the type and "fanciness" of the file-system a database will use if you know you don't need those additions, in the same way you use a stable fs for system files. You need a basic set of binaries one way or the other to access this data.

> I'm not sure using a helper program has as many assurances around it, and manipulating data in a db often won't involve any 'rm' command, though copy/replacing a text file might.

DBs still have files, they can be rm'ed. DBs also have other delete commands like 'DELETE FROM x'

My point is it's just as easy to "accidentally" delete data in a database as it is in text files.

> you said "what if the db has a bug or vulnerability", my point is you have to rely on something, even the kernel. The difference is how stable these things are, and databases can be very stable.

Someone else said that. I think the whole stability point is moot.

> not all kernel vulnerabilities will put the db at risk, it depends on the exposure to parts of the kernel. You can restrict the type and "fanciness" of the file-system a database will use if you know you don't need those additions, in the same way you use a stable fs for system files. You need a basic set of binaries one way or the other to access this data.

If a software vulnerability exposes text files like /etc/passwd then it can expose the database disk files in exactly the same way. Having a database format won't magically stop files from being read remotely.

It's also worth mentioning that most of the time it's not kernel vulnerabilities you need to be worried about (not that I'm saying they're not bad); any bug in software (e.g. Wordpress vulnerability) that allows an attacker to specify the source file to be read would put both your database config concept and the existing UNIX config layout at risk.