← writing
WRITING — CLICKHOUSE

ClickHouse for playback analytics, PostgreSQL for everything else

Two databases is not a failure of nerve. It is an admission that the workloads have nothing in common.

PUBLISHEDApr 2026
READING7 min
TOPICClickHouse
AUTHORgr-ixSaba Abbasi — backend, Baghdad

Playback events arrive at a rate that makes a relational database sad and answer questions that make a relational database sadder: distinct viewers per title per hour, buffering ratio by region, completion curves.

The split

PostgreSQL keeps everything with a lifecycle — subscriptions, entitlements, catalogue. ClickHouse keeps everything append-only. Nothing is written to both, and nothing joins across them at query time; the reporting layer asks each what it is good at.

What surprised me

Query planning matters more than schema. A MergeTree ordered by (title_id, event_time) answers the product questions in milliseconds and the finance questions in seconds — reversing the key reverses which team complains.

Materialised views did the rest. Pre-aggregating per hour cut dashboard latency by an order of magnitude, at the cost of a schema that now has opinions about what people will ask.

NEXT
Feb 20264 minPractice

On government projects the document is the deliverable

An SRS nobody reads is waste. An SRS that settles arguments is the cheapest code you will ever write.