I would much rather that they had used an existing database file format. Sqlite3 is robust and already present in the default installation of most Linux distributions. Querying system logs with SQL would be cool and likely faster than using the sd_journal API with all it's weird quirks.
If you want to store logs in a database, just use standard rsyslog. It has supported database backends pretty much since its inception at the dawn of the century. No need to reinvent anything.
> No need to reinvent anything.
Well I think we found the reason for journald's complexity right there, systemd devs and reinventing the wheel (plus breaking backwards compat in the process) is a match made in heaven
Text or text-like (e.g. text content with simple control char delimiters for metadata) would be far superior than the slow-down from Sqlite's safety mechanisms. Optimising logs for read, at the expense of write, is a bad pattern to me.
Read optimized? That is funny because reading logs from journald is dog slow compared to, you know, log files.
I was talking about alternatives like Sqlite. It might optimise complex querying, but writing to it is slower than simple appends.
There's an open source project which is a syslog daemon that stores logs in DuckDB. You can configure journald to forward logs to it.
https://github.com/phare/sloggo