<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Clickhouse on Lorbic</title><link>http://localhost:1313/tags/clickhouse/</link><description>Recent content in Clickhouse on Lorbic</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 30 Mar 2026 23:45:00 +0530</lastBuildDate><atom:link href="http://localhost:1313/tags/clickhouse/index.xml" rel="self" type="application/rss+xml"/><item><title>ClickHouse data masking with regex</title><link>http://localhost:1313/clickhouse-regex-data-masking/</link><pubDate>Tue, 31 Mar 2026 22:30:00 +0530</pubDate><guid>http://localhost:1313/clickhouse-regex-data-masking/</guid><description>&lt;p>If you&amp;rsquo;re running a production observability stack, you&amp;rsquo;ve already leaked PII. An engineer forgot to redact an email in a log line, or a JWT token ended up in a stack trace.&lt;/p>
&lt;p>In most databases, the only fix is to &lt;code>DELETE&lt;/code> the data—killing your metrics along with the sensitive info. But ClickHouse has a more elegant approach: &lt;strong>Data Masking Policies&lt;/strong>.&lt;/p>
&lt;p>By defining a policy at the role level, you can use regex to swap sensitive patterns with &lt;code>[REDACTED]&lt;/code> in real-time, before the query results even leave the server.&lt;/p></description></item><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><item><title>Can ClickHouse Replace Vector Databases? HNSW, Benchmarks &amp; SQL Setup</title><link>http://localhost:1313/clickhouse-as-a-vector-database/</link><pubDate>Wed, 14 Jan 2026 20:00:00 +0530</pubDate><guid>http://localhost:1313/clickhouse-as-a-vector-database/</guid><description>&lt;p>Everyone&amp;rsquo;s building AI apps now. And every AI app needs a place to stash embeddings. The instant your data grows beyond &amp;ldquo;fits in memory&amp;rdquo;, you need a vector database. Or do you?&lt;/p>
&lt;p>If you&amp;rsquo;re already running ClickHouse for analytics, here&amp;rsquo;s some good news: you might not need another database. ClickHouse can hold its own as a vector store. Not because it was built for it, but because it&amp;rsquo;s built to be fast at everything.&lt;/p></description></item><item><title>OLTP vs OLAP - Why You Need Two Databases</title><link>http://localhost:1313/oltp-vs-olap-why-you-need-two-databases/</link><pubDate>Sun, 11 Jan 2026 21:00:00 +0530</pubDate><guid>http://localhost:1313/oltp-vs-olap-why-you-need-two-databases/</guid><description>&lt;p>At a recent ClickHouse conference in New Delhi, I attended this Saturday. There were many interesting sessions, but one that stood out was a talk on multi-tenant analytics at scale. I was reminded of a fundamental truth in backend engineering: &amp;ldquo;The database that runs your app cannot be the database that analyzes your app&amp;rdquo;.&lt;/p>
&lt;p>Early in a startup&amp;rsquo;s life, we shove everything into one database. User profiles, session data, logs, and analytics events all live in the same Postgres, Mongo, or Couchbase instance. It works, until it throttles.&lt;/p></description></item></channel></rss>