# InfluxDB: Erklärung, Architektur & Use Cases 2026

InfluxDB ist eine spezialisierte Zeitreihendatenbank (Time Series Database, TSDB), die für die Speicherung und Analyse von zeitgestempelten Daten optimiert ist. Mit InfluxDB 3 Core steht eine Open-Source-Variante zur Verfügung. Dank der modernen IOx-Engine auf Rust-Basis ermöglicht sie High-Performance- und IoT-Monitoring und SQL-Abfragen in Echtzeit.

## Was ist InfluxDB?

InfluxDB ist ein [Datenbank-Management-System](https://www.ionos.de/digitalguide/hosting/hosting-technik/datenbankmanagementsystem-dbms-erklaert/), das von der Firma InfluxData entwickelt wurde. Die Datenbank ist auf Zeitreihendaten spezialisiert, also auf Daten, die mit einem Zeitstempel gespeichert und über Zeitintervalle hinweg ausgewertet werden.

InfluxDB ist in **mehreren Varianten verfügbar**: Für lokale und selbstverwaltete Umgebungen stehen InfluxDB 3 Core (Open Source, MIT/Apache-2-Lizenz) und InfluxDB 3 Enterprise zur Wahl. Beide sind seit April 2025 in der General-Availability-Version verfügbar. InfluxDB 3 Enterprise ist grundsätzlich zwar kommerziell, kann aber mit einer eingeschränkten At-Home-Lizenz kostenlos für nicht kommerzielle Heim- und Hobbyprojekte genutzt werden.

Für verwaltete Cloud-Szenarien bietet InfluxData unter anderem InfluxDB Cloud Serverless und InfluxDB Cloud Dedicated an. Darüber hinaus ist InfluxDB 3 seit Oktober 2025 auch als vollständig verwalteter Dienst sowohl in der Core- als auch in der Enterprise-Variante über Amazon Timestream for InfluxDB verfügbar. Dabei ist es wichtig, die beiden selbstverwalteten Varianten nicht gleichzusetzen: InfluxDB 3 Core ist als sogenannte Recent-Data Engine konzipiert, während InfluxDB 3 Enterprise für Langzeitspeicherung die empfohlene Wahl ist:

<table>
  <thead>
    <tr>
      <th>Kriterium</th>
      <th>InfluxDB 3 Core</th>
      <th>InfluxDB 3 Enterprise</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><strong>Ausrichtung</strong></td>
      <td>Recent-Data Engine</td>
      <td>Enterprise-Variante für produktive Umgebungen</td>
    </tr>
    <tr>
      <td><strong>Typische Datenbasis</strong></td>
      <td>Aktuelle Daten, typischerweise der letzten Stunden oder wenigen Tage</td>
      <td>Aktuelle und historische Daten</td>
    </tr>
    <tr>
      <td><strong>Geeignet für</strong></td>
      <td>Lokale Entwicklung, Tests, kleinere selbstverwaltete Umgebungen, aktuelle Zeitreihenanalysen</td>
      <td>Langzeitspeicherung, historische Analysen, Hochverfügbarkeit, produktive Workloads</td>
    </tr>
    <tr>
      <td><strong>Wichtige Funktionen</strong></td>
      <td>Verarbeitung aktueller Zeitreihendaten</td>
      <td>Kompaktierung, Read Replicas, Multi-Node-Deployments, feingranulare Sicherheitsfunktionen</td>
    </tr>
  </tbody>
</table>

Mit InfluxDB 3.x hat sich die technische Grundlage der Datenbank deutlich verändert. Frühere Versionen (InfluxDB 1 und InfluxDB 2) nutzten die TSM-Engine (Time-Structured Merge Tree). InfluxDB 3.x verwendet dagegen eine **neue Engine, die auf der IOx-Architektur basiert**. Sie nutzt [Apache Arrow](https://arrow.apache.org/ "Website von Apache Arrow") für spaltenorientierte In-Memory-Daten, Apache Parquet für persistente Speicherung, DataFusion als Query-Engine und Apache Flight für performante Datenübertragung.

Auch die Abfragesprache hat sich verändert. In älteren InfluxDB-Versionen spielte Flux eine zentrale Rolle. Für InfluxDB 3.x gilt das nicht mehr: [SQL](https://www.ionos.de/digitalguide/server/knowhow/was-ist-sql/) **ist die primäre Abfragesprache**. InfluxQL bleibt weiterhin verfügbar, vor allem für bestehende Workloads und Migrationen. Flux wird dagegen nicht mehr als Kernsprache von InfluxDB 3.x weitergeführt.

## Die wichtigsten Funktionen von InfluxDB 3

InfluxDB 3.x bringt mehrere technische Neuerungen mit, die vor allem für DevOps-, Monitoring- und Data-Engineering-Workloads relevant sind:

- **Spaltenorientierung:** InfluxDB 3.x nutzt Columnar Storage. Dadurch liest die Datenbank bei analytischen Abfragen nur die benötigten Spalten, nicht vollständige Datensätze.
- **SQL-Support:** SQL ist die primäre Abfragesprache in InfluxDB 3.x. InfluxQL bleibt zusätzlich für bestehende Zeitreihen-Workloads verfügbar.
- **Datenkompression:** Apache Parquet speichert Daten spaltenorientiert und komprimiert. Das reduziert den Speicherbedarf bei großen Zeitreihenbeständen.
- **Retention Periods:** In InfluxDB 3 steuern Retention Periods, wie lange zeitgestempelte Daten aufbewahrt werden, bevor sie aus Abfragen herausfallen und später automatisch gelöscht werden.

## Wann kommt InfluxDB zum Einsatz?

InfluxDB ist prädestiniert für Anwendungsfälle, in denen **Zeitreihen gespeichert, abgefragt und analysiert** werden müssen. Typische Einsatzbereiche und **Use Cases** sind:

- Monitoring von Servern, Containern und Cloud-Infrastrukturen
- Observability für Microservices, Kubernetes und verteilte Systeme
- IoT- und IIoT-Sensordaten
- Netzwerk- und Applikationsmetriken
- Log-, Trace- und Telemetriedaten
- Energiemonitoring
- Predictive Maintenance
- Anomalieerkennung und Pipelines für [Machine-Learning](https://www.ionos.de/digitalguide/online-marketing/web-analyse/was-ist-machine-learning-so-lernen-maschinen-denken/)

Dabei kann es sich um Millionen oder Milliarden eingehender Datenpunkte handeln, wie sie beispielsweise Geräte des [Internet of Things](https://www.ionos.de/digitalguide/websites/online-recht/internet-of-things/), industrielle Anlagen oder wissenschaftliche Messinstrumente in einem konstanten Datenstrom liefern. Diese Daten müssen schnell geschrieben und zeitnah ausgewertet werden.

Eine einfache Zeitreihe kann aus Datenquelle, Messwert und Zeitstempel bestehen, wie diese beispielhafte Zeitreihe zeigt:

<table>
  <thead>
    <tr>
      <th>Sensor</th>
      <th>Wert</th>
      <th>Zeit</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Sensor 1</td>
      <td>140,50</td>
      <td>23/06/2026 @ 10:00</td>
    </tr>
    <tr>
      <td>Sensor 2</td>
      <td>110,02</td>
      <td>23/06/2026 @ 10:00</td>
    </tr>
    <tr>
      <td>Sensor 1</td>
      <td>142,32</td>
      <td>23/06/2026 @ 10:05</td>
    </tr>
    <tr>
      <td>Sensor 2</td>
      <td>110,50</td>
      <td>23/06/2026 @ 10:05</td>
    </tr>
    <tr>
      <td>…</td>
      <td>…</td>
      <td>…</td>
    </tr>
  </tbody>
</table>

InfluxDB unterscheidet im Datenmodell zwischen **Tags und Fields**:

- **Tags** enthalten Metadaten und werden für Filterung und Gruppierung genutzt.
- **Fields** enthalten die eigentlichen Messwerte, die aggregiert, berechnet oder analysiert werden.

Im oben dargestellten Beispiel ist die erste Spalte also ein Tag, während die zweite ein Field ist.

## InfluxDB im Vergleich zu PostgreSQL und MongoDB

InfluxDB ersetzt weder relationale Datenbanken wie PostgreSQL noch dokumentenorientierte NoSQL-Datenbanken wie MongoDB. Die Datenbank ist auf Zeitreihendaten optimiert setzt im Vergleich zu anderen Datenbanksystemen einen anderen technischen Schwerpunkt.

[PostgreSQL](https://www.postgresql.org/ "Website PostgreSQL") arbeitet klassisch mit **Schema-on-Write**. Tabellen, Spalten, Datentypen und Constraints werden definiert, bevor Daten geschrieben werden. [MongoDB](https://www.mongodb.com/de-de "Website MongoDB") erlaubt flexiblere Dokumentstrukturen und wird häufig in Szenarien eingesetzt, in denen Daten erst beim Lesen stärker interpretiert werden. InfluxDB folgt einem spezialisierten Zeitreihenmodell: Jeder Datenpunkt besitzt einen Zeitstempel, Tags für Dimensionen und Fields für Messwerte.

<table>
  <thead>
    <tr>
      <th>Datenbank</th>
      <th>Datenmodell</th>
      <th>Typisches Schema-Verhalten</th>
      <th>Typischer Einsatz</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><strong>InfluxDB</strong></td>
      <td>Zeitreihenmodell mit Timestamp, Tags und Fields</td>
      <td>Flexibles Zeitreihenschema mit bewusstem Tag-/Field-Design</td>
      <td>Monitoring, IoT, Observability, Telemetrie, Predictive Maintenance</td>
    </tr>
    <tr>
      <td><strong>PostgreSQL</strong></td>
      <td>Relationales Modell mit Tabellen, Datentypen, Constraints und JOINs</td>
      <td>Schema-on-Write</td>
      <td>Transaktionsdaten, Geschäftslogik, ERP, CRM, relationale Anwendungen</td>
    </tr>
    <tr>
      <td><strong>MongoDB</strong></td>
      <td>Dokumentenmodell mit JSON-ähnlichen Dokumenten</td>
      <td>Flexible Dokumentstruktur, häufig mit spätem Schema-Design beim Lesen</td>
      <td>Semistrukturierte Daten, Content-Strukturen, Produktdaten, flexible Objektmodelle</td>
    </tr>
  </tbody>
</table>

## Wie funktioniert InfluxDB 3?

InfluxDB 3.x basiert auf einer neuen Storage- und Query-Architektur. Während InfluxDB 1.x und 2.x auf der TSM-Engine aufbauten, setzt InfluxDB 3.x auf eine Engine, die aus dem Projekt InfluxDB IOx hervorgegangen ist. Diese Engine wurde in [Rust](https://www.ionos.de/digitalguide/websites/web-entwicklung/rust-programmiersprache-vorgestellt/) entwickelt und nutzt offene Datenstandards aus dem Apache-Ökosystem.

Die wichtigsten Komponenten sind:

- **Apache Arrow:** spaltenorientiertes In-Memory-Format für analytische Verarbeitung
- **Apache Parquet:** spaltenorientiertes Speicherformat für persistente Daten
- **DataFusion:** SQL-Query-Engine für Planung, Optimierung und Ausführung von Abfragen
- **Apache Arrow Flight:** performante Datenübertragung für analytische Workloads
- **Rust:** Programmiersprache für eine performante und speichersichere Engine

Im Folgenden werden die wichtigsten Eigenschaften und Funktionen von InfluxDB 3.x genauer vorgestellt.

### Echtzeit-Analyse mit Apache Arrow

Apache Arrow ist ein zentraler Baustein von InfluxDB 3.x. Es sorgt dafür, dass Zeitreihendaten im Arbeitsspeicher **spaltenorientiert** verarbeitet werden können. Das ist vor allem für analytische Abfragen wichtig, bei denen nur bestimmte Messwerte, Tags oder Zeitfenster ausgewertet werden. Im Unterschied zu zeilenorientierten Datenbanken muss InfluxDB 3.x bei solchen Abfragen nicht ganze Datensätze lesen. Stattdessen kann die Datenbank gezielt auf die benötigten Spalten zugreifen. Das bringt mehrere Vorteile:

- schnellere Abfragen über große Zeiträume
- effizientere Aggregationen, etwa Durchschnittswerte, Maximalwerte oder Perzentile
- bessere Kompression ähnlicher Werte
- geringere I/O-Last bei analytischen Workloads

Dadurch eignet sich InfluxDB 3.x besser für **Real-time Analytics** als frühere Versionen, die stärker auf klassische Metrik-Workloads ausgelegt waren.

### Kardinalität ohne klassische Grenzen

Kardinalität beschreibt, wie viele eindeutige Serien bzw. Zeitreihen eine Datenbank verwaltet. In InfluxDB entsteht eine Serie aus der Kombination von Measurement, Tags und Fields. Hohe Kardinalität (High Cardinality) entsteht vor allem durch viele unterschiedliche Tag-Werte bzw. Tag-Kombinationen.

In älteren InfluxDB-Versionen konnte hohe Kardinalität die Performance deutlich beeinträchtigen. Besonders dynamische Tags waren problematisch, zum Beispiel:

- `container_id`
- `pod`
- `device_id`
- `request_id`
- `trace_id`

Solche Werte ändern sich häufig und erzeugen schnell sehr viele eindeutige Serien. Das ist vor allem in Kubernetes-, Cloud- und IoT-Umgebungen relevant. InfluxDB 3.x wurde für solche Workloads neu aufgebaut und unterstützt laut Hersteller in der Variante InfluxDB 3 Enterprise **Milliarden von Serien ohne klassische Kardinalitätslimits**.

Für Monitoring und Observability ist das ein wichtiger Vorteil: Teams können **mehr technische Dimensionen speichern und auswerten**, ohne Tags vorschnell entfernen oder Daten stark vereinfachen zu müssen. Trotzdem bleibt ein sauberes Schema wichtig. Tags eignen sich weiterhin für häufig gefilterte oder gruppierte Dimensionen, Fields für Messwerte, die aggregiert oder berechnet werden.

### Abfragen mit SQL und InfluxQL

InfluxDB 3.x unterstützt im Wesentlichen zwei Abfragesprachen:

- **SQL** für neue Projekte, analytische Abfragen und die Anbindung an bestehende Tools
- **InfluxQL** für klassische Zeitreihenabfragen und die Migration bestehender InfluxDB-1.x-Workloads

Flux spielt in InfluxDB 3.x nur noch eine Nebenrolle. Die Sprache befindet sich im Maintenance Mode und wird in InfluxDB 3.x nicht offiziell unterstützt. Das hat konkrete Konsequenzen für alle, die von InfluxDB 1.x oder 2.x migrieren: Bestehende Flux-Abfragen, Tasks und Dashboards lassen sich nicht automatisch übernehmen. Sie müssen vollständig in SQL oder InfluxQL neu geschrieben werden.

InfluxDB 3.x setzt bei Abfragen vor allem auf SQL. Die Sprache lässt sich gut in Analyse-, BI- und Data-Engineering-Workflows einfügen. Eine einfache SQL-Abfrage kann zum Beispiel aktuelle [CPU](https://www.ionos.de/digitalguide/server/knowhow/cpu/)-Werte auslesen:

```sql
SELECT
    time,
    host,
    usage_user
FROM cpu
WHERE time >= now() - INTERVAL '1 hour'
ORDER BY time DESC;
```

### Datenaufnahme mit Telegraf und Integrationen

Telegraf bleibt im InfluxDB-Ökosystem wichtig. Der Agent **sammelt Metriken, Events und Sensordaten** aus unterschiedlichen Quellen und schreibt sie in InfluxDB. Gerade in Monitoring-, IoT- und IIoT-Umgebungen ist Telegraf weiterhin relevant, weil viele Systeme und Protokolle über Plugins angebunden werden können.

Der **TICK-Stack** aus Telegraf, InfluxDB, Chronograf und Kapacitor spielt in modernen InfluxDB-3-Architekturen nicht mehr die gleiche zentrale Rolle wie bei älteren Versionen:

- **Telegraf** bleibt als Datensammler wichtig.
- **InfluxDB 3 Explorer**, **Grafana** und SQL-fähige BI-Tools übernehmen heute häufiger Visualisierung, Exploration und Analyse.
- **Chronograf** ist vor allem für klassische InfluxDB-1.x-Workloads relevant und in neuen InfluxDB-3-Setups meist nicht mehr die Standardoberfläche.

### Optimierung von Retention und Downsampling

Zeitreihendaten wachsen schnell. Deshalb sind Retention und Downsampling zentrale Konzepte.

- **Retention** legt fest, wie lange Daten gespeichert werden.
- **Downsampling** reduziert ältere Daten auf geringere Auflösungen, zum Beispiel von Sekundenwerten auf Minuten- oder Stundenaggregate.

In InfluxDB 3.x können hierfür SQL, externe Pipelines und die integrierte Processing Engine genutzt werden. Die Processing Engine ist eine eingebettete Python-VM, die Python-Plugins ausführt, welche auf definierte Datenbankereignisse reagieren.

Für produktive Architekturen bedeutet das: **Rohdaten können hochauflösend aufgenommen werden**, während ältere Daten verdichtet oder nach definierten Regeln gelöscht werden. Apache Parquet und Columnar Storage verbessern zusätzlich die Speichereffizienz.

## Use Case: AI und Predictive Maintenance

Ein aktueller Einsatzbereich für InfluxDB ist Predictive Maintenance. Dabei werden historische und aktuelle Maschinendaten analysiert, um Anomalien, Verschleißmuster oder Ausfallrisiken frühzeitig zu erkennen.

InfluxDB eignet sich für diesen Anwendungsfall, weil industrielle Sensordaten fast immer Zeitreihendaten sind. Maschinen liefern kontinuierlich Werte wie Temperatur, Druck, Vibration, Drehzahl, Stromverbrauch, Durchfluss oder Fehlerraten. Diese Daten werden mit Zeitstempel gespeichert und können anschließend für Modelle vorbereitet werden.

Ein typischer Ablauf sieht so aus:

1. Sensoren oder industrielle Gateways erfassen Maschinendaten.
2. Telegraf, MQTT, OPC UA oder eine andere Pipeline schreibt die Daten in InfluxDB.
3. SQL-Abfragen oder Python-Plugins bereiten Daten für Analysen vor.
4. Machine-Learning-Modelle erkennen Abweichungen vom Normalverhalten.
5. Dashboards oder Alerting-Systeme informieren Wartungsteams.

InfluxDB ist dabei nicht die vollständige Machine-Learning-Plattform. Die Datenbank dient als **performanter Zeitreihenspeicher und Analyse-Layer**. Besonders wichtig ist die Kombination aus historischen Daten und Live-Daten. Modelle können aktuelle Messwerte mit bekannten Mustern vergleichen und dadurch auf drohende Ausfälle hinweisen.


This is a markdown version of: [https://www.ionos.de/digitalguide/hosting/hosting-technik/was-ist-influxdb/](https://www.ionos.de/digitalguide/hosting/hosting-technik/was-ist-influxdb/) for AI/LLM consumption.