TimescaleDB vs. InfluxDB vs. ClickHouse: Datenbankauswahl für Time-Series

Für Netigo bauten wir NetFlow Manager — ein System, das Netzwerkverkehr von IPFIX/NetFlow-Sensoren in Echtzeit aufnimmt und analysiert, mit Peaks im GB/s-Bereich. Die Datenbankauswahl war kritisch. Falsche Wahl = System fällt unter Last oder kostet 5× mehr.

Wir evaluierten drei Kandidaten: TimescaleDB, InfluxDB, ClickHouse. Hier, was wir abwogen und warum wir TimescaleDB gewählt haben.

Das Workload, für das wir auswählten

• Write-heavy: 500 000 — 2 000 000 Zeilen/s Ingestion
• Zeilen typischerweise 100-200 Bytes (kompakter Event)
• Retention 90 Tage hot, 2 Jahre cold
• Query-Muster: Aggregationen über Zeitfenster (sum bytes pro src_ip pro Stunde letzte 24h), Top-N-Queries (Top-100 Flows nach Volumen)
• Konsumenten: API-Backend, Dashboards, Alerting-System

TimescaleDB — Postgres-Extension

Vorteile:

• Es ist Postgres. Alle kennen es, Tooling existiert, Backend-Integration trivial.
• SQL — keine neue Query-Sprache.
• Hyperpartitioning (Hypertable) und native Kompression — Tabelle automatisch zeitlich geshardet; ältere Chunks werden 10-20× kleiner komprimiert.
• Continuous Aggregates — vorberechnete stündliche/tägliche Rollup-Tabellen, automatisch aktualisiert.
• JOINs mit gewöhnlichen Tabellen (User, Config, Gerätemetadaten) ohne Verrenkungen — bei TSDBs selten.

Nachteile:

• Write-Throughput niedriger als ClickHouse. Auf unserer Hardware (32 Cores, NVMe-SSD) haben wir ~400k Inserts/s im Single-Node gemessen. Für 2M/s wäre ein Cluster nötig.
• Lizenzierung — Open-Source-Apache-2.0-Core, einige Enterprise-Features (Multi-Node, Advanced Compression) kosten Geld.
• Disk-Usage vor Compression ~30-50 % größer als ClickHouse.

InfluxDB — Time-Series-Purist

Vorteile:

• Rein für Time-Series konzipiert. Gute Benchmarks auf synthetischen Workloads.
• Retention Policies und Downsampling out-of-the-box.
• Kleinerer Disk-Footprint als Postgres/TimescaleDB.

Nachteile:

• Flux-Query-Sprache (InfluxDB 2.x) — noch eine Sprache, noch eine Lernkurve, weniger Leute können es. 3.x kehrt über IOx-Backend zu SQL zurück, aber das Ökosystem ist turbulent.
• Keine JOINs mit relationalen Daten. Wenn Sie Flows nach Gerätemetadaten (in Postgres) aggregieren wollen, machen Sie es in der App.
• Bei unserem Load-Test stießen wir auf Cardinality-Explosion — bei GB/s-Traffic gibt es Millionen einzigartiger src_ip × dst_ip-Paare; InfluxDB wurde langsamer.
• Historisch turbulent: Major-Versionen 1 → 2 → 3 wechselten Storage-Engine und Query-Sprache. Niemand bietet eine starke Langzeit-Stabilitätswette.

ClickHouse — Rohes Throughput-Monster

Vorteile:

• Höchster Write-Throughput. Auf der gleichen Hardware maßen wir 1,8M Inserts/s — fast 5× TimescaleDB.
• Kolumnar-Storage, aggressive Kompression, kleinster Disk-Footprint (30-40 % von TimescaleDB).
• SQL-ähnlicher Dialekt (CH hat einen eigenen, sehr nah am Standard-SQL).
• Ausgezeichnet für OLAP — Top-N, Aggregationen, Rollups.

Nachteile:

• Schwache Update/Delete-Operationen. ClickHouse ist append-optimiert. Deletes und Updates sind teuer und async. Ungeeignet für DSGVO-Deletes.
• Eventual Consistency bei Replikation. Für manche Use Cases (Audit-Trail) inakzeptabel.
• Operations-Komplexität — ZooKeeper/Keeper-Coordination, Sharding-Strategie, Merge-Tree-Tuning. Braucht dedizierten DevOps.
• Kleineres Ökosystem als Postgres. Manche Tools (z. B. Liquibase-Schema-Migrations) kennen es nicht.

Die Entscheidungsmatrix

Für Netigo bewerteten wir auf 5 Dimensionen:

• Write-Throughput: CH > TS > Influx. CH gewinnt um ~5×.
• Query-Expressivität: TS > CH > Influx. TS-SQL mit JOINs gegen Metadata-Tabellen gewann.
• Operations: TS > Influx > CH. TS ist „nur Postgres“.
• Team-Expertise: TS hoch. Das ganze Team kennt Postgres.
• Langzeit-Risiko: TS > CH > Influx. Postgres-Ökosystem ist am stabilsten.

Für unsere konkreten Zahlen (500k-2M Zeilen/s Write, JOINs nötig, kein dedizierter DBA) kam TimescaleDB als Optimum heraus. CH würde Hardware sparen, aber der Ops-Overhead macht das zunichte.

Wann Sie anders wählen würden

ClickHouse wählen, wenn:

• Write-Throughput > 3M/s auf Single-Node erforderlich ist
• Sie ein dediziertes Platform-Team oder DBA haben
• Sie keine JOINs mit Transaktionsdaten brauchen (Analytics-only)
• DSGVO-Deletes oder häufige Updates kein Use Case sind

InfluxDB wählen, wenn:

• Reiner IoT/Observability-Use-Case mit niedriger Cardinality
• Team Flux toleriert oder auf 3.x-Stabilität wartet
• Out-of-the-box-Downsampling ohne Custom-Code nötig

Netigo-Ergebnis nach 10 Monaten

• TimescaleDB, Single-Node (vorerst), 64 Cores, 1TB NVMe
• Durchschnitt Write-Throughput 650k Zeilen/s
• P99-Query-Latenz auf Top-100-Queries: 180 ms
• Kompressionsrate auf 7-Tage-Chunks: 12×
• Disk-Storage: 2,3 TB für 90 Tage Hot-Data
• Scaling-Plan: Übergang zu TimescaleDB-Multi-Node bei > 1,5M/s (aktuelle Reserve 2,3×)

Zum Mitnehmen

TSDB-Auswahl geht nicht um „schnellster gewinnt“. Es geht darum, wie gut die Wahl in Ihren Gesamt-Stack, Team-Know-how und operative Kapazität passt. Für 80 % der Projekte mit Time-Series-Daten ist TimescaleDB der pragmatische Default — außer Sie haben einen expliziten Grund, anders zu gehen. ClickHouse ist stärker für OLAP-Warehousing; InfluxDB für IoT mit niedriger Cardinality.

Der wichtigste Rat: messen Sie Ihr echtes Workload. Synthetische Zahlen sagen nichts. Prototyp hochziehen, 10 % des erwarteten Traffics draufgeben, beobachten was passiert.