You’ve probably spent hours—if not days—configuring OpenTelemetry collectors, wrangling agents, and untangling YAML files just to get basic Postgres metrics into your dashboard. And when you finally get the pipeline working, you notice a 10 to 15-second delay. In the world of real-time systems, 15 seconds is an eternity. Your database could be melting down, and your observability stack is still buffering.
Observability shouldn’t require a PhD in pipeline configuration just to find out your database is on fire.
Enter pg_stat_ch, a new Postgres extension that does something so blindingly obvious it almost feels wrong: it exports every single Postgres metric directly to ClickHouse. No middlemen. No bloated collectors. No standard protocols translating data back and forth. Just a raw, high-performance pipeline straight from the source to the analytics engine.
On Hacker News, the immediate reaction from the standards-conscious crowd was predictable: “Wouldn’t it make sense for this to export all those metrics via OTLP to an OTEL collector, which in its own could export data to a ClickHouse instance?”
No. It wouldn’t.
If your goal is to check boxes on an enterprise architecture diagram, by all means, build the OTLP pipeline. But if your goal is real-time, low-latency decision-making, adding a collector in the middle is like hiring a translator for a conversation between two people who already speak the same language.
Standards are great until they become the bottleneck they were supposed to eliminate.
The entire promise of ClickHouse is speed. The entire pain point of Postgres metric collection is the overhead of extracting and shipping that data without impacting the database itself. By cutting out the OpenTelemetry middleman, pg_stat_ch achieves something rare in modern infrastructure: it just works, and it works fast.
Yes, there is a trade-off. You are sacrificing interoperability. You can’t easily swap out ClickHouse for Datadog or Prometheus next Tuesday without ripping out the extension. You are deviating from the sacred OpenTelemetry best practices that vendors love to preach.
But let’s be honest about what those best practices actually deliver: universal compatibility at the cost of performance. They ensure that every tool can talk to every other tool, slowly.
A metric that arrives in milliseconds is worth infinitely more than a perfectly standardized one that arrives too late.
If you are running Postgres and ClickHouse in your stack, you already have the two most powerful tools for their respective jobs. Stop forcing them to communicate through a committee-designed middleware layer. Install the extension, point it at your ClickHouse instance, and get back to building your product instead of maintaining your metrics pipeline.
FAQ
Q: What about interoperability with other tools?
A: You lose it. pg_stat_ch is a direct pipe from Postgres to ClickHouse. If you need to send metrics to Datadog or Prometheus as well, you'll need a separate pipeline. That's the price of speed.
Q: What's the practical implication?
A: If you're already using ClickHouse for analytics, you can now get real-time Postgres metrics into your dashboards with zero middleware latency and minimal configuration overhead.
Q: What's the contrarian take?
A: OpenTelemetry is overkill for high-performance Postgres monitoring. The obsession with standard protocols is forcing engineering teams to build slow, complex pipelines when a direct database-to-database extension is vastly superior.