[nexo-v1]

This sounds a lot like structured logging with a fresh coat of paint. Wide events are nice conceptual model, but if you’ve been doing structured logs seriously, especially with something like Loki or ELK stack, you’re already capturing rich context per event — including things like user info, request paths, even DB queries if needed.

I’ve been using Loki recently and really like the approach: it stores log data in object storage and supports on-the-fly processing and extraction. You can build alerts and dashboards off it without needing to pre-aggregate or force everything into a metrics pipeline.

The real friction in all of these systems is instrumentation. You still need to get that structured event data out of your app code in a consistent way, and that part is rarely seamless unless your runtime or framework does most of it for free. So while wide events are a clean unification model, the dev overhead to emit them with enough fidelity is still very real.

[wbh1]

You are correct — wide events are essentially equivalent to structured logs. Charity Majors says as much in her blog post linked at the top of this article.

> The building block of o11y 2.0 is wide, structured log events

Wide events and structured logs are often used interchangeably. One caveat is that in "wide, structured log events" you're only emitting one [giant] log for each request coming through your service. In contrast, I still see many people using structured logs but in the "old fashioned" way of emitting multiple log lines per request.

[valyala]

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...

[rbranson]

No, wide events are quasi-relational. Read the literature please. I’ve never seen a structured log implementation that is anything remotely relational, it’s just a bunch of random junk thrown into a pile with maybe some common tags.

[esafak]

Can you expand? What makes the event relational; consistency of tags?

[jiggawatts]

Relational would be to not repeat yourself — written by jiggawatts on Hacker News, 2025 May.

It causes write amplification and slow queries. — written by jiggawatts on Hacker News, 2025 May.

Some would argue that it’s too hard to solve, but those same people are ingesting a petabyte of logs per hour, which is a bigger problem if you ask me. — written by jiggawatts on Hacker News, 2025 May.

[polynomial]

This seems related to normalization, just going by your example.