Stop Buying Purpose-Built Observability Databases. ClickHouse Is Eating Them Alive.

You know that sinking feeling when the monthly observability bill arrives and it’s bigger than your entire infrastructure budget? Yeah. We need to talk about that.

Here’s the dirty secret of the observability world: the specialized time-series databases you were told to buy—InfluxDB, TimescaleDB, whatever your vendor flew in to pitch—are getting demolished by a database that was never even designed for time-series workloads. That database is ClickHouse. And it’s not winning because it’s faster in some benchmark. It’s winning because it makes your storage bill disappear.

The best infrastructure decisions aren’t made in architecture meetings. They’re made when the finance team starts asking questions about the AWS bill.

Let me walk you through what’s actually happening. ClickHouse was built by Yandex for analytics—web traffic analysis, adtech, the kind of thing where you’re slicing billions of rows every which way. It’s a columnar database. It compresses aggressively. It was never meant to be an observability backend. And yet, companies are throwing petabytes of logs, traces, and metrics at it and watching their costs crater by 5x, 10x, sometimes more.

How? It comes down to compression. When you store observability data in a row-oriented database, every log line or metric point takes up roughly the space you’d expect. But ClickHouse stores data in columns. That means all your timestamp values sit together. All your service names sit together. All your HTTP status codes sit together. And here’s the thing about columnar storage: similar data compresses beautifully. A column of HTTP status codes that’s 99% “200” compresses to almost nothing. A column of timestamps with high temporal locality compresses to a fraction of its raw size.

Compression isn’t a feature. It’s the moat. The database that stores the same data at one-tenth the cost doesn’t need to be ten times better—it just needs to not be ten times worse at everything else.

Now you might be thinking: but what about query speed? Isn’t that why we chose our current observability tool? Sure, speed matters. And ClickHouse is fast—brutally fast—on the kind of queries observability demands. Range queries over time windows, aggregations across services, group-by operations on high-cardinality dimensions. These are literally what ClickHouse was built for. The irony is that “general-purpose analytics” and “observability” have almost identical query patterns. The specialized databases weren’t specializing in something different—they were specializing in the same thing, just worse.

I’ve seen teams spend months migrating from ElasticSearch or InfluxDB to ClickHouse and cut their observability spend by 80% while getting faster queries. Not 10% faster. Orders of magnitude faster. The kind of speed where you stop writing careful, optimized queries and just throw raw SQL at the thing because it doesn’t matter anymore.

When a tool makes you stop optimizing, you’ve found the right tool. When a tool makes you stop apologizing to finance, you’ve found the right architecture.

But here’s the twist nobody talks about: the real story isn’t about ClickHouse at all. It’s about what “specialized” means in infrastructure. For years, the industry sold us on the idea that specialized databases would outperform general-purpose ones because they were purpose-built for specific workloads. It sounded logical. It was wrong. The specialized databases optimized for the wrong thing—query patterns—while ignoring the thing that actually kills you at scale: storage economics.

At small scale, nobody cares about compression. You’ve got gigabytes of logs, your database handles it fine, and the bill is rounding error. But observability data is the fastest-growing dataset in most organizations. Logs breed logs. Metrics multiply. Traces explode. And the curve is exponential. At petabyte scale, the difference between 10x compression and 2x compression isn’t a line item—it’s the difference between observability being a tool and observability being a hostage situation.

Specialization is a tax you pay for someone else’s opinion about what matters. At scale, the only opinion that matters is the storage bill.

The observability vendors know this. That’s why every major observability platform—Grafana, Datadog, Uber’s internal stack, Cloudflare’s analytics—has either moved to ClickHouse or is moving to ClickHouse. The holdouts are either locked into legacy contracts or haven’t done the math yet. The ones who have done the math aren’t going back.

So if you’re an engineer or architect looking at your observability pipeline and feeling that quiet dread about where the costs are heading, here’s my advice: stop evaluating databases on query benchmarks. Start evaluating them on compression ratios. Start asking vendors not “how fast can you query” but “how small can you store.” Because at the scale you’re heading toward, storage isn’t a feature. It’s survival.

The observability wars are over. The general-purpose database won. And the reason it won is the reason nobody saw coming: it turns out the most specialized thing you can do for observability is to be relentlessly, brutally, obsessively efficient with storage. Everything else is just a UI problem.