> Primarily append-based, hence robust to corruption

It's so robust, it doesn't even let you modify the journal if you want to (e.g. https://github.com/systemd/systemd/issues/20673).

> Support for in-line compression

Mind that journald only supports compressing single lines, but not the whole journal (https://github.com/systemd/systemd/issues/31358), which is pretty limiting.

Modifying the existing journal really sounds like the wrong solution. Just "journalctl --rotate" the file and throw out the one with accidental PII. Journal files are not great for long-term storage or search. You can export the old file and filter out manually if you really want to preserve that one https://www.freedesktop.org/wiki/Software/systemd/export/

In what situations is it a harder problem than this?

In sicily we'd call this "vuliri a vutti china e a mugghieri 'mbriaca".

It's a tradeoff, if you do full compression clearly it won't be fast.

You're free to compress it again before archiving it.

> Primarily append-based > Seekable

Text logs are append-based and seekable as well.

> Support for in-line Forward Secure Sealing

I once typed an SSH password in the username field, and the only way to erase that was to erase all the logs. So this has some significant downsides.

Also, I am tired of waiting minutes for a journalctl query to load.

> I once typed an SSH password in the username field, and the only way to erase that was to erase all the logs. So this has some significant downsides.

I hope this was a personal system. Changing logs in this manner would have almost certainly led to your dismissal anywhere I ever worked. This anecdote just re-enforces the need for Forward Secure Sealing.

No, I just left it there.