Every few years the observability world gets a new religion. Usually it’s marketing. This one came with receipts.
The pitch is “observability 2.0.” Stop pre-chopping your telemetry into metrics, logs, and traces. Store rich wide events, one fat row per thing-that-happened with every dimension attached, in a columnar database, and compute whatever you need at query time.
Sounds like a slide. Then ClickHouse published what they actually run, and the slide turned into an architecture.
The numbers that ended the argument
ClickHouse runs their own observability on ClickHouse, a system they call LogHouse. In about a year it grew from 19 PB to over 100 PB, across roughly 500 trillion rows.
The interesting part isn’t the size. It’s what they replaced to get there.
Their OTel-based collection pipeline needed around 8,000 CPU cores to handle 20 million log lines per second, and the edge collectors were still dropping lines under load. They wrote a leaner byte-for-byte shipper that does 37 million logs per second on 70 cores. Roughly 20x the volume on under 10% of the compute.
Their stated philosophy: store everything, aggregate nothing.
That’s not a vendor saying “trust us.” That’s an engineering team showing the bill.
Why this matters for the three pillars
The three-pillars model made sense when storage and compute were expensive and you had to decide up front what to keep.
Metrics pre-aggregate into time series and throw away the detail. Cheap, fast, but you can only ask questions you decided to ask in advance. The infamous “high cardinality” problem is just the model punishing you for wanting detail you didn’t pre-declare.
Logs and traces keep the detail, then you pay through the nose to index and search it.
Wide events collapse all that. One event carries the metric dimensions and the trace context and the log detail. You don’t choose in advance. You ask the question later, against the raw data, and a columnar store answers it fast because that’s what columnar stores are for.
The cardinality tax mostly disappears, because you’re no longer pre-aggregating into time series that explode the moment you add a user_id tag.
When this is actually for you
I’ll be straight. Most Series B-D teams are not going to rip out their observability stack this quarter, and they shouldn’t.
But it’s worth a serious look if a few things are true.
Your bill is dominated by metric cardinality. You keep getting told to drop tags you actually need. Wide events sidestep the whole problem.
You’re already paying real vendor lock-in cost. OTel-native, ClickHouse-backed backends exist now as real products and open source. ClickStack, which is OSS, ClickHouse-native, and OTel-compatible, landed in 2025 and does logs, traces, metrics, and session replay in one stack. Netflix and eBay run observability on ClickHouse too. The build-vs-buy math is no longer “build a database from scratch.”
You keep wishing you’d kept the detail. Every time an incident ends with “we sampled that away” or “we don’t have that dimension,” you’re paying the three-pillars tax in MTTR.
The honest caveats
This is not free. You’re trading a managed SaaS for an architecture you operate. A columnar store at scale is real infrastructure with real tuning. ClickHouse’s numbers are ClickHouse’s, a company whose entire job is running ClickHouse well. Your mileage will be worse, at least at first.
And “store everything” still costs money to store. Cheaper per byte, sure, but the discipline shifts from “what do I drop” to “how long do I keep it.” Don’t mistake a better cost curve for no cost.
The takeaway
The three pillars weren’t wrong. They were a sensible answer to 2010’s constraints. Those constraints moved.
If your observability pain is fundamentally a cardinality-and-cost pain, the wide-events model isn’t hype anymore. There’s a 100-petabyte production system and a 20x compute number proving it works. Worth understanding before your next renewal.
If you want to figure out where your observability money is actually going before you re-architect anything, that’s the reliability costs breakdown.
— Youn