Loki doesn't work well with structured logs and wide events because it has weak support for log fields with many unique values such as trace_id, span_id, user_id, etc. (aka high-cardinality fields). The recommended way to store structured logs with such fields in Loki is to put them into a big JSON and store it as log message. Later this JSON must be parsed at query time in order to apply various filters and aggregations on log fields. Such an approach doesn't scale well, since Loki needs to read all the log messages with all the logs fields encoded inside JSON log messages during query execution. This requires a lot of additional read IO and CPU for reading, unpacking and parsing the log messages. This also worsens data compression at the storage, which slows down query execution even more.

The much better approach is to store data per every log field into column-based storage. This significantly improves query performance, since only the data for the requested columns must be read from the storage, and this per-column data usually has much better compression rate, so it occupies less storage space.

Read more about this at https://itnext.io/why-victorialogs-is-a-better-alternative-t...