[← Blog](https://watasu.io/blog) May 4, 2026 # ClickHouse: dashboards over billions of rows, one command away When we opened Watasu in April, ClickHouse shipped in early access — and quickly became the add-on you asked about most. Today it’s **generally available**, with a full plan ladder from a €15 dev instance to multi-shard clusters built for billions of rows. ## What ClickHouse is, and why you might want it Most apps keep their data in a transactional database like PostgreSQL — and they should. It’s built for many small reads and writes: load this user, update that order. But ask it a different kind of question — *“average session length per day, per country, over the last six months”* — across a hundred million rows, and you’ll feel it. Row-oriented databases store data record by record, so wide analytical scans churn through everything. ClickHouse stores data by **column** instead. When a query touches three columns out of forty, it reads exactly those three — compressed, in big sequential chunks, in parallel. The result feels like a different category of tool: aggregations over millions or billions of rows that return in seconds, on append-heavy data that would make a transactional database weep. Good fits, from what we’ve seen so far: - **Product analytics** — every click, page view, and feature event, queryable while it’s still being written - **Audit logs at scale** — append forever, slice instantly when someone asks “who changed this?” - **Time series** — metrics, sensor data, anything with a timestamp and a firehose behind it - **Dashboards** — wide aggregations that stay interactive instead of timing out And the honest counterpart: don’t use it as your transactional database. ClickHouse is not built for OLTP, and you’ll hate it for that. Keep PostgreSQL for the orders; let ClickHouse explain them. ## One command, like everything else ``` watasu addons:create clickhouse --app my-app ``` Connection details land in your app’s config vars; any standard ClickHouse client library works. Need to poke around interactively? ``` watasu clickhouse:cli --app my-app ``` ## A plan ladder with an honest gap in it Three tiers, and the jump between the first two is deliberately more than “a bigger box”: - **Hobby (€15–€60/mo)** — a single node on network-backed storage. Explicitly non-production: it’s for development, exploration, and small staging, with manual backups only. - **Standard (€80–€260/mo)** — production begins here, and the topology changes underneath you: one shard with **two replicas across two German zones**, on **local NVMe**, with scheduled backups by default. - **Premium (€600–€2,200/mo)** — multi-shard scale-out with two replicas per shard and distributed tables, for datasets that outgrow a single node. We’d rather draw that line clearly than let a “small production” instance quietly be neither. The full rate card is on the [pricing page](https://watasu.io/pricing#clickhouse). ## Backups that assume the worst Like every Watasu database, ClickHouse restores are **non-destructive**: a restore creates a replacement add-on you can inspect, and you promote it only when you’re satisfied. Capture a manual backup any time with `watasu addons:backups:capture`; Standard and Premium add scheduled backups on top. One tip from the team: validate your restore path before you need it. ClickHouse archives can be large, and an incident is the wrong moment for surprises. While you’re at it — ClickHouse loves materialized views, so pre-aggregate the queries your dashboards run most. ## Get started Attach one to a staging app and point your event stream at it — the [ClickHouse docs](https://docs.watasu.io/addons/clickhouse/) cover the details, and the [pricing page](https://watasu.io/pricing#clickhouse) has every plan. Questions, or a workload you’re not sure fits? We’re at . Happy querying — and may the fourth be with your aggregations.