<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Observability on Lorbic</title><link>http://localhost:1313/tags/observability/</link><description>Recent content in Observability on Lorbic</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 30 Mar 2026 22:45:00 +0530</lastBuildDate><atom:link href="http://localhost:1313/tags/observability/index.xml" rel="self" type="application/rss+xml"/><item><title>ClickHouse vs. Postgres: When to Move Your Logs Out of a Relational DB</title><link>http://localhost:1313/clickhouse-vs-postgres-log-storage/</link><pubDate>Mon, 30 Mar 2026 22:45:00 +0530</pubDate><guid>http://localhost:1313/clickhouse-vs-postgres-log-storage/</guid><description>&lt;p>Postgres is the most reliable tool in my stack. It handles users, configurations, and complex relations without breaking a sweat. But databases, like any physical system, have a &amp;ldquo;design limit&amp;rdquo;. For Postgres, that limit usually appears when you try to use it as a dumping ground for high-velocity logs and metrics.&lt;/p>
&lt;p>When your &lt;code>ANALYZE&lt;/code> commands start taking minutes and your indexes consume more RAM than your data, you aren&amp;rsquo;t facing a Postgres bug; you&amp;rsquo;re facing an architectural mismatch.&lt;/p></description></item></channel></rss>