I don't agree with that argument, sqlite is totally the right tool for the job, it provides consistency, reliability, an api you can query anything upon, transactions, indexing, tools... And fits into files.
You currently can't trust systemd log storage at all, even on my own laptop it manages to have some corruption... Querying is very poor and inefficient, indexing is unreliable... And that's exactly what I expect, building a database is hard.
The issue with NFS and SQLite is that posix advisory locks
do not work, or do not work well, on many NFS installations.
As long as advisory locks work over NFS, or as long as there
is only one client trying to access the database at a time, so
that locks are not really needed, SQLite works fine
over NFS. NFS is a lot slower, but that's just the nature
of NFS and SQLite can't do anything about that.
You can ask SQLite to use dot-file locking instead of
posix advisory locking. Or you can ask it to simply ignore
locking all together. In both cases, SQLite will work
on even a broken NFS system, though with the corresponding
concurrency limitations.
Fair. In my experience, the fact that NFS is both pervasive and often broken, for something like a system-wide log manager you can't always assume that your root fs is reliable.
Is dot-file locking a compile- or run-time option?
That's great, but you've completely ignored theamk's argument that sqlite is the wrong tool for the job.