InfluxDB

Kurzfazit

InfluxDB ist die etablierte Open-Source-Zeitreihendatenbank für alles, was zeitgestempelt einläuft, Sensorwerte, Metriken, IoT-Telemetrie. Mit InfluxDB 3 (GA seit 2025) hat InfluxData die Engine komplett in Rust neu geschrieben und auf den Apache-Arrow/Parquet/DataFusion-Stack umgestellt. Das bringt drei greifbare Vorteile: SQL als primäre Abfragesprache, drastisch bessere Speicherkompression und saubere Schnittstellen zu Python-, Pandas- und ML-Frameworks. Für KI-Projekte auf Zeitreihen, Predictive Maintenance, Anomalieerkennung, Netzlast-Forecasting, ist InfluxDB damit ein solider Speicher-Layer. Schwächen: kein deutscher Support, Multi-Node-HA nur in der Enterprise-Variante, und der Wechsel von v1/v2 nach v3 ist kein triviales Upgrade.

Für wen ist InfluxDB?

Industrie- und Energieversorger: Wer SCADA-Daten, Druck- oder Temperaturmessreihen langfristig speichern und auswerten muss, findet in InfluxDB die passende Speicherform. Die OSS-Variante kann on-premise betrieben werden, relevant für KRITIS-Betreiber, die Daten nicht aus dem eigenen Rechenzentrum geben dürfen.

IoT- und Produkt-Teams: Hardware-Hersteller, die Geräte-Telemetrie sammeln (Smart-Home, Fahrzeug, Industrial IoT), nutzen InfluxDB als Backend. Die hohe Schreib-Performance erlaubt Millionen Sensorwerte pro Sekunde auf moderater Hardware. Über die Python Processing Engine in v3 lassen sich Aggregationen und Anreicherungen direkt in der DB ausführen, statt einen separaten Streaming-Layer aufzusetzen.

Data-Science- und ML-Teams: Wer Anomalieerkennung, Forecasting oder Predictive-Maintenance-Modelle auf Zeitreihen trainiert, profitiert von der nativen Arrow/Parquet-Kompatibilität, Daten landen direkt in Pandas-DataFrames, ohne ETL-Zwischenschritte. Das ist ein echter Hebel gegenüber älteren Historian-Lösungen, deren Schnittstellen oft proprietär und langsam sind.

DevOps und SRE: Klassischer Use Case: Metriken aus Servern, Containern und Anwendungen in InfluxDB schreiben, mit Grafana visualisieren, Telegraf als Collector. Die Toolchain ist seit zehn Jahren erprobt und bei vielen Hosting-Anbietern als Default-Stack verfügbar.

Forschung und Labor: Hochfrequente Messreihen aus Versuchsständen, Spektrometern, Wettermessungen, InfluxDB ist hier oft Default-Speicher, weil OSS-Kostenfrei und Python-freundlich.

Weniger geeignet für: Klassische Geschäftsdaten (Kunden, Bestellungen, Rechnungen, dafür Postgres oder MySQL), Volltextsuche (Elasticsearch oder OpenSearch sind besser), und Anwender ohne Datenbank-Betriebs-Know-how, die eine schlüsselfertige UI-Plattform erwarten.

Preise im Detail

Plan	Preis	Was du bekommst
InfluxDB 3 Core (OSS)	0 USD	Vollständige Engine unter Apache 2.0, Single-Node, Community-Support, alle Schreib-/Leseoperationen, Python Processing Engine
InfluxDB 3 Enterprise	Custom (Trial 30 Tage)	OSS + Multi-Node-HA, Read Replicas, SAML/SSO, Enterprise-Security, kommerzieller Support
Cloud Serverless	Nutzungsbasiert (250 USD Startguthaben)	Data In 0,0025 USD/MB, Queries 0,012 USD/100 Executions, Storage 0,002 USD/GB-Stunde, Data Out 0,09 USD/GB, EU Frankfurt verfügbar
Cloud Dedicated	Custom (CPU/RAM/Storage)	Single-Tenant, unbegrenzte Skalierung, HA, optional Private Networking und SAML/SSO
Amazon Timestream for InfluxDB	AWS-Verbrauchspreise	InfluxDB als AWS-Managed-Service, abgerechnet über AWS-Konto inkl. AWS-Credits

Einordnung: Für Entwicklung, Prototyping und kleine Produktionssetups ist InfluxDB 3 Core kostenlos und ohne Lizenzbeschränkung produktionstauglich, kein Marketing-Trick, sondern echte Apache-2.0-Lizenz. Cloud Serverless ist attraktiv für kleine bis mittlere Workloads, kann bei hohem Datendurchsatz aber teurer werden als Self-Hosting auf einer dedizierten VM. Für KRITIS-Betreiber und alles, was unter NIS2 fällt, ist Cloud Dedicated oder Self-Hosted der einzig saubere Pfad, Multi-Tenant-Setups scheiden in regulierten Branchen meistens aus. Amazon Timestream for InfluxDB ist eine interessante Option für Teams, die ohnehin tief in AWS arbeiten und Abrechnung sowie IAM-Integration aus einer Hand wollen.

Stärken im Detail

Schreib-Performance ist die Kernkompetenz. Eine moderate Maschine (8 vCPU, 32 GB RAM) verarbeitet Hunderttausende bis Millionen Schreibvorgänge pro Sekunde, das ist eine andere Größenordnung als bei Postgres oder MySQL. Für Sensor-Netze, IoT-Flotten oder hochfrequente Monitoring-Stacks ist diese Eigenschaft der entscheidende Grund, überhaupt eine spezialisierte Zeitreihendatenbank zu wählen.

InfluxDB 3 räumt mit Altlasten auf. Die in Rust neu geschriebene Engine löst die zwei größten Schmerzpunkte der v2-Generation: Kardinalitäts-Limits (jetzt praktisch unbegrenzte unique series) und die ungeliebte Flux-Sprache. SQL ist in v3 die primäre Abfragesprache, InfluxQL bleibt als Kompatibilitätsschicht erhalten. Wer Postgres oder ein Data-Warehouse kennt, kann sofort produktiv abfragen.

Apache-Arrow-Stack öffnet das Ökosystem. Daten liegen intern als Parquet vor und werden via Arrow direkt in Python-, R- oder DuckDB-Sessions geladen, ohne Serialisierungskosten. Für ML-Teams ist das ein echter Hebel: Statt CSV-Exports zu produzieren, lädt Pandas oder Polars die Daten direkt. oder können auf diese Daten zugreifen, ohne sie vorher zu kopieren.

EU-Region Frankfurt für Cloud Serverless. Das ist der entscheidende Unterschied zu vielen US-zentrischen Datenbanken: Wer Cloud-Komfort will, kann seine Daten in Frankfurt auf AWS hosten lassen. Damit ist die Cloud-Variante für DACH-Unternehmen ohne Workaround DSGVO-konform, vorausgesetzt, der Standard-AVV reicht.

OSS-Lizenz ohne Tricks. Im Unterschied zu vielen DB-Anbietern, die zur Server Side Public License (SSPL) oder Business Source License (BSL) gewechselt sind, bleibt InfluxDB 3 Core unter Apache 2.0. Du kannst die DB beliebig einsetzen, modifizieren und auch als Managed Service anbieten. Diese Klarheit ist im aktuellen OSS-Klima ein Wettbewerbsvorteil.

Python Processing Engine. Neu in v3: Du kannst Python-Code direkt in der DB ausführen, um Daten beim Schreiben oder Lesen zu transformieren, Downsampling, Anreicherung mit ML-Vorhersagen, Format-Konvertierungen. Das spart in vielen Pipelines einen separaten Stream-Processing-Layer (Kafka Streams, Flink) ein.

Schwächen ehrlich betrachtet

Kein deutschsprachiger kommerzieller Support. InfluxData ist ein US-Unternehmen mit englischsprachiger Dokumentation und Community. Enterprise-Support gibt es, aber Reaktionen kommen aus US-Zeitzonen. Für DACH-Unternehmen, die garantierte Reaktionszeiten auf Deutsch brauchen, ist das eine Lücke, die du nur über lokale Beratungspartner schließen kannst.

Migration v1/v2 nach v3 ist Arbeit. Wer in den letzten Jahren mit Flux gearbeitet hat, kann die Queries nicht 1:1 nach v3 übernehmen. SQL ist zwar einfacher, aber die Logik muss neu formuliert werden. Auch das Datenmodell ist in v3 geringfügig anders (Tags und Fields werden anders interpretiert). InfluxData stellt Migrationsleitfäden bereit, aber für große Bestände ist das ein eigenes Projekt.

Single-Node in der OSS-Variante. InfluxDB 3 Core läuft als Single Node, keine eingebaute Replikation, kein automatisches Failover. Wer Hochverfügbarkeit braucht, muss zu Enterprise oder Cloud Dedicated greifen. Für DevOps-Monitoring oder Forschung ist das akzeptabel; für KRITIS-Produktion eine echte Hürde.

Operativer Aufwand wird unterschätzt. „Open Source ist kostenlos” stimmt nur für die Lizenz. Backup-Strategie, Retention-Policies, Storage-Sizing, Compaction-Tuning, das sind alles Aufgaben, die ein DBA übernehmen muss. Wer das Know-how nicht hat, zahlt am Ende mehr für Engineering-Zeit als für eine Cloud-Lizenz.

Cloud Serverless skaliert nicht-linear. Die Preisstruktur (Data In + Queries + Storage + Data Out) klingt günstig, kann bei hohem Volumen aber überraschen. Eine Pipeline, die 1 TB/Monat schreibt, abfragt und re-exportiert, landet schnell im vierstelligen Bereich. Ein FinOps-Review nach 4–6 Wochen Produktivbetrieb ist Pflicht.

Kein UI für Endnutzer. InfluxDB ist eine Datenbank, kein Analytics-Tool. Für Dashboards, Alerts und Visualisierungen brauchst du oder eine vergleichbare Lösung. Im v2-Zeitalter gab es eine integrierte UI (Chronograf), die in v3 reduziert wurde, der Fokus liegt jetzt klar auf API-First.

Schwächen bei Mixed Workloads. InfluxDB ist auf Zeitreihen optimiert. Wer Joins zwischen Sensordaten und großen Stammdaten-Tabellen oder komplexe Aggregationen über mehrere Dimensionen braucht, läuft schnell an Grenzen. Hier ist ein klassisches Data Warehouse (, ) oder ein Hybrid-Setup besser.

Alternativen im Vergleich

Wenn du…	…nimm stattdessen
Tiefe Postgres-Integration und SQL-Vollumfang willst	TimescaleDB (Postgres-Extension, keine eigene Tool-Seite)
Metriken und Monitoring im DevOps-Stack	Prometheus + (Pull-Modell, Open Source)
Industrielle Historian-Welt mit OPC UA und SCADA-Tiefe
Fertige IoT-Plattform mit Edge, KI und Cloud aus einer Hand
Time-Series-Storage als Teil eines Data Warehouse	oder

Erwähnenswert ohne eigene Tool-Seite: QuestDB (Open-Source-TSDB mit SQL-Fokus, sehr schnell), VictoriaMetrics (Prometheus-kompatibel, MIT-Lizenz, beliebt im Monitoring-Bereich), Apache Druid (für hochdimensionale Analytics-Workloads) und kdb+ (proprietär, aber Marktstandard im Finanzhandel). InfluxDB bleibt der bekannteste Name in dieser Kategorie, und mit v3 hat InfluxData den Anschluss an die moderne Open-Data-Lakehouse-Welt zurückgewonnen.

So steigst du ein

Schritt 1: Lokal mit Docker testen. Starte InfluxDB 3 Core in einem Container (docker run -p 8086:8086 influxdb:3-core) und schreibe Testdaten via HTTP-API oder Python-Client. Nimm dir 30–60 Minuten, um das Schema-Modell zu verstehen: Bucket, Measurement, Tags, Fields, Timestamp. Wer das Modell falsch wählt (z. B. zu hohe Kardinalität bei Tags), zahlt später mit Performance-Problemen.

Schritt 2: Realistische Workload mit echten Daten füttern. Schreibe ein Pilotsetup, das einen Tag echte Produktionsdaten ingestiert, SCADA-Werte, Sensorwerte, App-Metriken. Miss Schreib-Latenz, Speicherverbrauch und Query-Performance. Erst auf Basis dieser Zahlen entscheidest du, ob OSS reicht oder ob du Cloud/Enterprise brauchst.

Schritt 3: Anbindung an Grafana, Python und ML-Pipeline. Verbinde als Visualisierungs-Layer (offizielles InfluxDB-Plugin), schreibe ein Python-Script, das via influxdb_client_3 Daten abfragt und in Pandas lädt, und teste die Integration mit deinem ML-Framework. Erst wenn dieser Loop steht, hast du einen produktiven Stack.

Schritt 4 (optional, Produktion): Cloud Serverless oder Dedicated evaluieren. Wenn du auf produktive Lasten gehst und keine eigene DBA-Kapazität hast, evaluiere die Cloud-Optionen. Für DACH-Unternehmen ist Cloud Serverless in Frankfurt der schnellste DSGVO-konforme Weg, vorausgesetzt, dein Workload passt zu Multi-Tenant. Andernfalls Cloud Dedicated oder Enterprise mit Single-Tenant-Setup.

Ein konkretes Beispiel

Ein regionaler Stromnetzbetreiber mit Sitz in Augsburg betreibt 280 Ortsnetzstationen mit jeweils 12–18 Messpunkten (Spannung, Strom, Wirk-/Blindleistung). Bisher landeten die Daten in einer alten Microsoft-SQL-Server-Instanz, die bei 24 Mio. Datenpunkten pro Tag spürbar langsamer wurde. Die IT migriert auf InfluxDB 3 Core auf zwei dedizierten Linux-Servern in einem DACH-Rechenzentrum, eine Primary, eine Read-Replica via Skript-Sync. liest die Daten für die Netzleitstellen-Dashboards. Ein Python-Service trainiert wöchentlich ein Anomalieerkennungs-Modell (Isolation Forest) auf den letzten 30 Tagen und schreibt Anomalie-Scores zurück in einen separaten Bucket. Ergebnis nach 6 Monaten: Speicherbedarf gesunken von 1,8 TB auf 280 GB (Parquet-Kompression), Query-Latenz für typische Dashboards von 4–8 Sekunden auf unter 200 ms, jährliche Lizenzkosten 0 € statt 28.000 € (SQL-Server-Enterprise). Operative Kosten: zwei halbe Tage DBA-Aufwand pro Monat plus Hardware.

DSGVO & Datenschutz

• Datenhosting OSS / Enterprise (Self-Hosted): Du bestimmst den Speicherort. Beim Betrieb in DACH-Rechenzentren entstehen keine DSGVO-Fragen zur Datenübermittlung, InfluxData hat keinen Zugriff.
• Datenhosting Cloud Serverless: AWS EU Frankfurt (eu-central-1-1) oder US East (us-east-1-1). Für DACH-Workloads zwingend Frankfurt wählen.
• Datenhosting Cloud Dedicated: Single-Tenant, Region wählbar, auch in EU verfügbar. Empfohlener Pfad für KRITIS-/regulierte Branchen ohne eigene DBA-Kapazität.
• Datennutzung: InfluxData nutzt Kundendaten nicht für eigenes Training oder Produktentwicklung. Telemetrie über Cluster-Nutzung kann anonymisiert erfasst werden, abschaltbar.
• Auftragsverarbeitung (AVV): Verfügbar für Cloud Serverless, Cloud Dedicated und Enterprise. Bei Self-Hosting nicht erforderlich, weil keine Datenverarbeitung durch Dritte stattfindet.
• Empfehlung für Unternehmen: Für KRITIS-Betreiber (Energie, Wasser, Telekommunikation) sind Self-Hosted OSS/Enterprise oder Cloud Dedicated in Frankfurt der saubere Pfad. Cloud Serverless ist für nicht-regulierte Workloads in DACH unproblematisch. Vor produktivem Einsatz: Datenschutz-Folgenabschätzung, AVV beim Datenschutzbeauftragten gegenprüfen lassen.

Gut kombiniert mit

• , die De-facto-Standard-Kombination für Zeitreihen-Visualisierung. Grafana bietet ein offizielles InfluxDB-Plugin mit SQL- und InfluxQL-Support. Für Dashboards, Alerts und multi-source Korrelationen die natürliche Ergänzung.
• , wer ML-Modelle auf Zeitreihen trainiert (Forecasting, Anomalieerkennung, Predictive Maintenance), kann SageMaker als Trainings- und Inference-Layer auf InfluxDB-Daten betreiben. Der Arrow/Parquet-Export macht den Datenfluss effizient.
• , für Industrial-IoT-Szenarien: Siemens Industrial Edge übernimmt die Edge-Verarbeitung (Maschinen-Daten, Vorverarbeitung), InfluxDB sammelt die Daten zentral und stellt sie für Analytics bereit.

Unser Testurteil

InfluxDB verdient 4 von 5 Sternen. Mit der v3-Generation hat InfluxData die wichtigsten Altlasten (Flux-Sprache, Kardinalitäts-Limits, schwache Pandas-Integration) hinter sich gelassen und steht heute technisch sehr stark da. Apache-2.0-Lizenz, EU-Frankfurt-Region und der saubere Arrow/Parquet-Stack machen InfluxDB zur ersten Wahl für Open-Source-Zeitreihen in regulierten Branchen. Den fünften Stern verliert es durch fehlenden deutschsprachigen Support, das Single-Node-Limit der OSS-Variante und den Migrationsaufwand für bestehende v1/v2-Installationen. Für neue Projekte ist InfluxDB 3 Core der pragmatischste Einstieg in eine moderne Zeitreihen-Architektur; für Produktion mit HA-Anspruch lohnt sich Enterprise oder Cloud Dedicated.

Was wir bemerkt haben

• April 2025, InfluxDB 3 Core und Enterprise haben General Availability erreicht. Die in Rust neu geschriebene Engine ersetzt die alte Go-Codebasis von v1/v2 und löst die langjährigen Probleme mit Kardinalität und Flux-Akzeptanz. Bestehende v2-Installationen laufen weiter, der Migrationspfad ist aber kein Knopfdruck.
• 2024, Amazon hat Timestream for InfluxDB veröffentlicht, InfluxDB als AWS-Managed-Service. Das ist ein deutliches Vertrauenssignal: AWS bietet selten Drittanbieter-DBs als Managed Service an, wenn die Technologie nicht überzeugt.
• 2023, InfluxData hat die Cloud-Strategie deutlich verändert und Cloud Serverless als Standard-Cloud-Option positioniert. Ältere Cloud-Versionen (“InfluxDB Cloud 1” und “Cloud 2”) werden schrittweise abgekündigt, Bestandskunden müssen migrieren.
• 2022–2023, Die Flux-Sprache, die in v2 noch als strategisch beworben wurde, ist mit v3 faktisch deprecated. SQL ist jetzt die primäre Abfragesprache. Wer in Flux investiert hat, muss umsteigen, ein Lehrstück, wie schnell sich technische Entscheidungen in DB-Ökosystemen drehen können.
• Mai 2026, Die EU-Region Frankfurt (eu-central-1-1) ist weiterhin die einzige europäische Cloud-Serverless-Region. Wer mehr regionale Flexibilität (z. B. EU-West/Irland) braucht, muss auf Cloud Dedicated oder Self-Hosting ausweichen.