Sure, I'll try my best to put some concrete numbers on it:

On a file of ~1M lines (350 MB), ripgrep returns a query matching 22k lines in 1.9s.

(Separately: We have gzip log rotation for old logs. A log with 1.9M lines (106 MB gzipped) on disk can be searched from cold in 1.3s by ripgrep, whilst still being ergonomic. Maybe a different compressor is better?)

On a service unit filter over ~218k lines, `journalctl -u service --since <...> -g query` returns 4.8k matching lines in 4.127s (and this is after having warmed the cache by returning the unfiltered query cold, in 11.9s. I don't have root to clear the disk cache

I should have ran the filtered query first but ah well, since the difference is already so large it doesn't matter that the filtered journalctl query gets an unfair advantage)

Comparing input rates:

    ripgrep (plain): 576k line/sec
    ripgrep (gz): 1.4M line/sec
    journalctl (-u, --since, -g): 53k line/sec

I don't have a great deal of understanding of journald's internals, so perhaps there is some variable here that is unreasonably unfavourable to journald.

Transcript

    user@machine:~/log$ time rg query aservice.log | wc -l
    22628

    real    0m1.859s
    user    0m0.109s
    sys     0m0.909s
    user@machine:~/log$ wc -l aservice.log
    1071606 aservice4.log


    user@machine:~$ time journalctl --since '2026-08-16' -u myservice@1.service | wc -l
    218661

    real    0m11.914s
    user    0m10.729s
    sys     0m0.798s

    user@machine:~$ time journalctl --since '2026-08-16' -u myservice@1.service -g query | wc -l
    4804

    real    0m4.127s
    user    0m3.727s
    sys     0m0.186s

Probably more painful on the day to day is how `journalctl -fu myservice` seems to stall for on the order of 5 to 10s, sometimes. I can't reproduce at the moment and maybe it only happens on some machines, but if you were interested in 'real-world anecdata' it's something to maybe note.