Your app writes a million events a day to Postgres. Dashboard queries time out. You bolt on Elasticsearch, then Grafana, then a cron job that aggregates yesterday into a CSV nobody trusts. OLTP databases were built for row-by-row transactions — not "show me unique users by province for the last 90 days across 800 million rows."
ClickHouse is the open-source columnar database built for that second problem. ~48k GitHub stars, SQL interface, absurd speed on analytical queries, and a self-host path that doesn't require signing up for another SaaS meter. It's not a web app with a cute UI — it's infrastructure you run when logs, metrics, and product analytics outgrow MySQL.
What it actually does
ClickHouse is an OLAP (online analytical processing) database. Data is stored by column, not row, which means aggregations — counts, sums, percentiles, group-bys over huge datasets — run orders of magnitude faster than in Postgres or MySQL.
Typical workloads:
- Web and product analytics (page views, funnels, retention)
- Application and infrastructure logs at scale
- Time-series metrics and observability backends
- A "speed layer" in front of your warehouse — fast recent data in ClickHouse, cold history in S3 or Snowflake
You query with SQL. Inserts are batch-friendly; updates and deletes exist but ClickHouse shines when you're appending events and scanning billions of rows read-mostly. Tools like Grafana, Metabase, and custom dashboards connect over HTTP (port 8123) or the native protocol (9000).
There's also ClickHouse Local — run analytical queries on Parquet/CSV files without standing up a server. Handy for one-off investigations; production analytics usually means clickhouse-server.
Why self-host ClickHouse?
Cost at volume. ClickHouse Cloud starts around $50/month and scales with compute and storage. Self-hosted on a dedicated or VPS with NVMe can win when you're ingesting terabytes and running dashboards all day — you pay for the box, not per query.
Data stays where you put it. Event streams contain user behaviour, IP addresses, and business metrics. Canadian teams with residency requirements often want analytics data on Canadian hardware, not in a default US cloud region.
You already run the stack. If you're self-hosting Uptime Kuma, n8n, and app backends on Docker, adding ClickHouse for the metrics those systems generate is a natural next step — one more container, not a new vendor login.
Open source core. The server is Apache 2.0 licensed. You can inspect, fork, and run it anywhere Docker or Linux runs — no feature gate on "self-hosted edition."
What running it takes
Official Docker image:
docker run -d \
--name clickhouse-server \
--ulimit nofile=262144:262144 \
-p 8123:8123 -p 9000:9000 \
-v clickhouse_data:/var/lib/clickhouse \
clickhouse/clickhouse-serverMount a volume at /var/lib/clickhouse — that's your data. The raised file descriptor limit matters; don't skip it.
Hardware is the story. ClickHouse loves RAM and fast disk. Rule of thumb from their docs: roughly 4 GB RAM per CPU core for general analytics; more for heavy warehousing. NVMe SSD beats spinning rust by a lot. This is not a "512 MB homelab sidebar" app — a serious single-node setup often starts at 16–32 GB RAM and fast storage.
Not your app database. Keep user accounts and orders in Postgres. Replicate or stream events into ClickHouse via Kafka, MaterializedMySQL, cron ETL, or application-side batch inserts. Using ClickHouse as primary OLTP will hurt.
Lock down ports — don't expose 8123 to the internet without auth and TLS. Create non-default users via CLICKHOUSE_USER / CLICKHOUSE_PASSWORD env vars or init scripts in /docker-entrypoint-initdb.d. Back up the data directory and test restores; merging parts wrong is a bad day.
Who it's for (and who should skip it)
Good fit: SaaS teams drowning in event data, ops shops centralizing logs and metrics, data-minded devs who want sub-second dashboards on billions of rows, anyone comparing self-hosted OLAP vs warehouse bills.
Maybe skip it: if you have 50k rows and one chart — Postgres is fine. If nobody on the team will tune schemas, partitions, and retention policies, managed ClickHouse Cloud or a simpler analytics SaaS is less operational load. If you need ARM on a Raspberry Pi, check CPU compatibility — recent ClickHouse images have specific ARM requirements.
Hosting it in Canada
We provision Docker and dedicated hosting on Canadian infrastructure for workloads that need RAM, NVMe, and someone watching disk growth — ClickHouse included when you're ready to move analytics off Postgres or US cloud warehouses.
Tell us approximate daily event volume and retention window — we'll size RAM and disk honestly, or tell you if you're not big enough to need ClickHouse yet.
