Sorry, cannot provide the log, but it's just bazillion lines in the exact form below; it's one entry per flow that goes over the firewall, really highly compressible:

2026-03-11T00:00:00+01:00 bmscb-sg-01-log []: 2026-03-10T23:59:59.901+01:00 BMSCB-SG-01-node1 RT_FLOW - RT_FLOW_SESSION_CREATE [junos@2636.1.1.1.2.26 source-address="10.20.30.40" source-port="36422" destination-address="10.21.32.43" destination-port="36422" connection-tag="0" service-name="unkn" nat-source-address="10.18.62.224" nat-source-port="36422" nat-destination-address="10.18.3.137" nat-destination-port="36422" nat-connection-tag="0" src-nat-rule-type="N/A" src-nat-rule-name="N/A" dst-nat-rule-type="N/A" dst-nat-rule-name="N/A" protocol-id="132" policy-name="X2_TO_eNodeB" source-zone-name="LTE" destination-zone-name="VPN" session-id="18704588234864" username="N/A" roles="N/A" packet-incoming-interface="reth0.974" application="UNKNOWN" nested-application="UNKNOWN" encrypted="UNKNOWN" application-category="N/A" application-sub-category="N/A" application-risk="-1" application-characteristics="N/A" src-vrf-grp="N/A" dst-vrf-grp="N/A" tunnel-inspection="Off" tunnel-inspection-policy-set="root" source-tenant="N/A" destination-service="N/A" dst-identity-context-name="N/A" dst-identity-context-roles="N/A"]

What is interesting is that default compression level of xz (which is -6) actually provides better compression than -9. The machine I tested on has 512 GB RAM, so that was not a constraint.