ClickHouse: columnar-Analytics-Datenbank für Aggregate über Milliarden Zeilen

Was ist ClickHouse?

ClickHouse ist eine columnar (spaltenorientierte) Online-Analytical-Processing-Datenbank, die 2009 bei Yandex (Russlands Google-Equivalent) für Web-Analytics entwickelt wurde. 2016 als Open Source unter Apache 2.0 veröffentlicht, seit 2021 von der eigenständigen US-Firma ClickHouse Inc. (mit Sitz in Kalifornien) weitergetrieben. Im Mai 2026 ist Version 25 stabil mit Vector-Search, JSON-Improvements und Hybrid-OLTP-Fähigkeiten.

Der entscheidende Unterschied zu PostgreSQL oder MySQL: ClickHouse speichert Daten spaltenweise statt zeilenweise. Eine Zeile in einer SQL-Tabelle wird über alle Spalten zusammenhängend abgelegt; eine ClickHouse-Tabelle speichert pro Spalte ein Array. Dieser Unterschied klingt akademisch, hat aber massive Performance-Implikationen.

Wer eine Aggregat-Query wie SELECT count(), avg(price) FROM bookings WHERE year=2025 ausführt, muss in Postgres alle Spalten jeder gelesenen Zeile durch den I/O-Kanal zwingen -- 80 Prozent der gelesenen Daten werden verworfen. ClickHouse liest nur die Spalten year und price, plus komprimiert columnar-typisch um Faktor 10-30 -- I/O sinkt um Faktor 50-100. Auf realistischen Workloads ist ClickHouse 50-100x schneller als Postgres bei Aggregat-Reports über Millionen bis Milliarden Zeilen.

ClickHouse Cloud (clickhouse.com/cloud) bietet einen Free-Tier ab USD 0 für Prototypen, Production startet bei USD 0.32 pro vCPU-Stunde. Self-Host läuft als Docker-Container, RPM/DEB-Paket oder Kubernetes-Operator. EU-Region (Frankfurt, Amsterdam) verfügbar. Open-Source-Version und Cloud-Version teilen den gleichen Code, kein Open-Core-Modell mit Enterprise-Features.

Warum es wichtig ist

ClickHouse ist 2026 die Default-Wahl für Analytics-Workloads -- aber NICHT der Ersatz für eine Operational-DB. Der Unterschied ist wichtig.

Drei Indikatoren, dass ClickHouse die richtige Wahl ist. Erstens: Datenmenge im Aggregat-Bereich. Wer über 100 Millionen oder mehr Einträge pro Tag aggregiert (z.B. Web-Analytics für eine grosse Site, Telemetrie-Daten aus IoT-Geräten, Order-Booking-Logs eines Shops), bekommt mit Postgres unter Last Antwortzeiten im Minuten-Bereich. ClickHouse antwortet in Sekunden bis Sub-Sekunden.

Zweitens: Append-Only-Pattern. ClickHouse ist auf hohe Insert-Raten optimiert (Millionen Einträge pro Sekunde), aber Updates und Deletes sind teuer (ALTER TABLE ... DELETE/UPDATE läuft als Background-Mutation). Wer Logs, Events, Telemetrie, Click-Tracking schreibt, passt perfekt -- Daten kommen rein, werden nicht modifiziert.

Drittens: Pre-Aggregation und Materialized Views als Standard. ClickHouse bietet Materialized Views, die bei jedem Insert automatisch aktualisiert werden -- eine Tagessummen-Tabelle ist immer aktuell, ohne separate Scheduling-Logik. AggregatingMergeTree-Engine kombiniert Pre-Aggregation mit columnar Storage.

Für CH-KMU im Mai 2026 sehen wir drei typische Einsatz-Fälle. Erster Fall: SaaS-Produkt mit eigener Web-Analytics statt Google Analytics (DSGVO-Vorteil) -- 10-100 Millionen Pageviews pro Monat in ClickHouse, Reports in Sekunden statt Minuten. Zweiter Fall: IoT-Telemetrie für Industriekunden -- Sensor-Daten von 100+ Geräten über Jahre, Aggregat-Reports für Predictive-Maintenance. Dritter Fall: Treuhand-Reporting auf historischen Buchungs-Daten -- mehrere Jahre Buchungs-Logs, Aggregate für Branchen-Vergleiche und Trend-Analysen.

Wichtig: kein OLTP. ClickHouse ist nicht für hochfrequente Einzel-INSERT-UPDATE-Operationen gebaut. Wer pro Sekunde 100 INSERTS in seine Buchhaltung schreibt, gehört in Postgres. ClickHouse arbeitet im Batch -- pro Insert-Batch idealerweise 1000-100k Einträge.

Wie es funktioniert

ClickHouse ist ein Multi-Threaded Server in C++, der über HTTP/TCP und das native ClickHouse-Wire-Protokoll erreichbar ist. Eine Instanz handhabt typisch 100k-10M Einträge pro Sekunde Schreib-Last, abhängig von Schema-Komplexität und Hardware.

Die zentrale Engine ist MergeTree -- die Familie aller Storage-Engines, die persistente columnar-Tabellen speichert. Varianten: ReplacingMergeTree (Dedup auf Sortier-Schlüssel), SummingMergeTree (Auto-Summierung), AggregatingMergeTree (Materialized-View-Basis), ReplicatedMergeTree (mit Zookeeper/ClickHouse Keeper für HA).

Ein minimal-produktiver Setup:

CREATE TABLE events ( event_time DateTime64(3, 'Europe/Zurich'), user_id UInt64, event_type LowCardinality(String), page_url String, duration_ms UInt32, metadata Map(String, String) ) ENGINE = MergeTree PARTITION BY toYYYYMM(event_time) ORDER BY (event_time, user_id) TTL event_time + INTERVAL 2 YEAR;

Die PARTITION BY-Klausel teilt Daten monatlich -- alte Partitionen können einfach gedropt werden, oder via TTL automatisch entfernt. ORDER BY definiert den primary key für die Sortierung; das ist nicht UNIQUE, sondern der physische Storage-Sort. LowCardinality optimiert Spalten mit wenigen unterschiedlichen Werten (z.B. event_type, country) -- 5-10x Compression-Verbesserung.

Queries: SELECT toStartOfDay(event_time) AS day, count(), avg(duration_ms) FROM events WHERE event_time > now() - INTERVAL 7 DAY GROUP BY day ORDER BY day. Auf 100 Millionen Zeilen typisch unter 100 ms.

Materialized Views: CREATE MATERIALIZED VIEW events_daily ENGINE = AggregatingMergeTree() ORDER BY (day, event_type) AS SELECT toStartOfDay(event_time) AS day, event_type, countState() AS count_state FROM events GROUP BY day, event_type. Jeder neue INSERT in events aktualisiert die Materialized View automatisch.

Replikation: ReplicatedMergeTree mit 2-3 Replicas plus ClickHouse Keeper (Zookeeper-Replacement, seit 2024 stabil). Cluster-Mode shard über Distributed-Engine. Self-Host-Setup nicht trivial -- für KMU oft besser ClickHouse Cloud mit gleicher Apache-2.0-Engine.

ClickHouse in 5 Schritten produktiv

1. 01Entscheidung Cloud vs. Self-Host: bei < 1 TB Daten und ohne Datenresidenz-Pflicht -> ClickHouse Cloud Frankfurt. Bei strikter CH-Datenresidenz oder > 1 TB -> Self-Host auf Hetzner.
2. 02Schema designen: MergeTree-Engine mit PARTITION BY (zeitbasiert), ORDER BY (häufigste Filter-Spalten), LowCardinality für wenig-distinkte Spalten, TTL für Retention.
3. 03Ingestion-Pipeline bauen: HTTP-Insert oder native Wire-Protocol, Batches von 1000-100k Einträgen, Kafka oder NATS als Buffer bei hoher Insert-Last.
4. 04Materialized Views für häufige Aggregate anlegen: tagliche/wöchentliche Sumar-Tabellen mit AggregatingMergeTree, automatische Aktualisierung bei jedem Insert.
5. 05Monitoring und Backup: clickhouse_exporter für Prometheus, system.query_log für Slow-Queries, BACKUP-Command in S3-kompatiblen Speicher (seit Version 24 stabil).

Wann ClickHouse einsetzen

Die richtige Wahl, wenn (a) Aggregate-Queries über Millionen oder Milliarden Zeilen schnell laufen müssen, (b) das Daten-Muster Append-Only oder nahe daran ist, oder (c) Web-Analytics, Log-Aggregation oder Telemetrie-Workloads gebaut werden.

Konkrete Szenarien: eigene Web-Analytics-Lösung statt Google Analytics (DSGVO-Vorteil), IoT-Telemetrie mit Sensor-Daten von Hunderten oder Tausenden Geräten, Application-Performance-Monitoring (APM) mit Tracing-Spans, Security-Information-and-Event-Management (SIEM) mit Auth-Logs, Werbe-Click-Tracking, Order-Booking-Analytics für Shops, Financial-Markets-Tick-Data, Game-Analytics.

Neue 2026-Use-Cases: LLM-Observability mit Token-Usage-Tracking über Millionen Calls (LangSmith / Phoenix backends), AI-Agent-Telemetrie für Tool-Calls und Latency-Tracking, RAG-Pipeline-Metriken für Recall- und Precision-Tracking.

ClickHouse Cloud ist attraktiv für Teams ohne ClickHouse-Operations-Erfahrung -- EU-Region Frankfurt für DSGVO, Pay-per-Use ab USD 0 für Free-Tier, Production ab ein paar Hundert USD pro Monat für mittlere Workloads. Self-Host lohnt ab mehreren TB Daten oder bei strenger Datenresidenz-Pflicht.

Wann NICHT

Niemals als OLTP-DB für eine Anwendung mit hochfrequenten Einzel-INSERT-UPDATE-DELETE-Operationen. ClickHouse arbeitet im Batch, Updates sind teuer (Background-Mutations), DELETEs sind teuer. Wer in einer Treuhand-Anwendung pro Sekunde 10 Buchungen schreibt und korrigiert, gehört in Postgres.

Für kleine Datenmengen (< 10 Millionen Zeilen) ist ClickHouse Overkill. Postgres mit gut gesetzten Indexes oder einer ColumnStore-Erweiterung (Citus, TimescaleDB-Hypertable) macht denselben Job mit weniger Komplexität.

Für Transaktions-Sicherheit über mehrere Operationen ist ClickHouse nicht geeignet -- es bietet kein ACID auf Multi-Statement-Transaktions-Ebene. Wer Geld-Buchungen mit konsistenten Soll/Haben-Einträgen braucht, gehört in Postgres.

Für Single-Document-Lookups (typische SELECT * FROM table WHERE id=42 Queries) ist Postgres oder Redis schneller. ClickHouse ist auf Aggregate optimiert, nicht auf Random-Access.

Für Operations ohne Cloud-Akzeptanz und ohne ClickHouse-Erfahrung im Team: Self-Host-ClickHouse-Cluster mit Replikation und Sharding ist deutlich komplexer als Postgres oder MySQL. Ohne ein paar Wochen Operations-Investment macht man sich keinen Gefallen.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. ClickHouse 25 Release Notes · 2026-05
2. ClickHouse Cloud pricing and regions · 2026-05
3. ClickHouse Apache 2.0 license · 2026-05
4. ClickHouse vs PostgreSQL performance benchmark · 2026-04