InfluxDB: Erklärung, Ar­chi­tek­tur & Use Cases 2026

InfluxDB ist eine spe­zia­li­sier­te Zeit­rei­hen­da­ten­bank (Time Series Database, TSDB), die für die Spei­che­rung und Analyse von zeit­ge­stem­pel­ten Daten optimiert ist. Mit InfluxDB 3 Core steht eine Open-Source-Variante zur Verfügung. Dank der modernen IOx-Engine auf Rust-Basis er­mög­licht sie High-Per­for­mance- und IoT-Mo­ni­to­ring und SQL-Abfragen in Echtzeit.

Was ist InfluxDB?

InfluxDB ist ein Datenbank-Ma­nage­ment-System, das von der Firma In­flux­Data ent­wi­ckelt wurde. Die Datenbank ist auf Zeit­rei­hen­da­ten spe­zia­li­siert, also auf Daten, die mit einem Zeit­stem­pel ge­spei­chert und über Zeit­in­ter­val­le hinweg aus­ge­wer­tet werden.

InfluxDB ist in mehreren Varianten verfügbar: Für lokale und selbst­ver­wal­te­te Um­ge­bun­gen stehen InfluxDB 3 Core (Open Source, MIT/Apache-2-Lizenz) und InfluxDB 3 En­ter­pri­se zur Wahl. Beide sind seit April 2025 in der General-Avai­la­bi­li­ty-Version verfügbar. InfluxDB 3 En­ter­pri­se ist grund­sätz­lich zwar kom­mer­zi­ell, kann aber mit einer ein­ge­schränk­ten At-Home-Lizenz kostenlos für nicht kom­mer­zi­el­le Heim- und Hob­by­pro­jek­te genutzt werden.

Für ver­wal­te­te Cloud-Szenarien bietet In­flux­Data unter anderem InfluxDB Cloud Ser­ver­less und InfluxDB Cloud Dedicated an. Darüber hinaus ist InfluxDB 3 seit Oktober 2025 auch als voll­stän­dig ver­wal­te­ter Dienst sowohl in der Core- als auch in der En­ter­pri­se-Variante über Amazon Timestream for InfluxDB verfügbar. Dabei ist es wichtig, die beiden selbst­ver­wal­te­ten Varianten nicht gleich­zu­set­zen: InfluxDB 3 Core ist als so­ge­nann­te Recent-Data Engine kon­zi­piert, während InfluxDB 3 En­ter­pri­se für Lang­zeit­spei­che­rung die emp­foh­le­ne Wahl ist:

Mit InfluxDB 3.x hat sich die tech­ni­sche Grundlage der Datenbank deutlich verändert. Frühere Versionen (InfluxDB 1 und InfluxDB 2) nutzten die TSM-Engine (Time-Struc­tu­red Merge Tree). InfluxDB 3.x verwendet dagegen eine neue Engine, die auf der IOx-Ar­chi­tek­tur basiert. Sie nutzt Apache Arrow für spal­ten­ori­en­tier­te In-Memory-Daten, Apache Parquet für per­sis­ten­te Spei­che­rung, Da­ta­Fu­si­on als Query-Engine und Apache Flight für per­for­man­te Da­ten­über­tra­gung.

Auch die Ab­fra­ge­spra­che hat sich verändert. In älteren InfluxDB-Versionen spielte Flux eine zentrale Rolle. Für InfluxDB 3.x gilt das nicht mehr: SQL ist die primäre Ab­fra­ge­spra­che. InfluxQL bleibt weiterhin verfügbar, vor allem für be­stehen­de Workloads und Mi­gra­tio­nen. Flux wird dagegen nicht mehr als Kern­spra­che von InfluxDB 3.x wei­ter­ge­führt.

Die wich­tigs­ten Funk­tio­nen von InfluxDB 3

InfluxDB 3.x bringt mehrere tech­ni­sche Neue­run­gen mit, die vor allem für DevOps-, Mo­ni­to­ring- und Data-En­gi­nee­ring-Workloads relevant sind:

• Spal­ten­ori­en­tie­rung: InfluxDB 3.x nutzt Columnar Storage. Dadurch liest die Datenbank bei ana­ly­ti­schen Abfragen nur die be­nö­tig­ten Spalten, nicht voll­stän­di­ge Da­ten­sät­ze.
• SQL-Support: SQL ist die primäre Ab­fra­ge­spra­che in InfluxDB 3.x. InfluxQL bleibt zu­sätz­lich für be­stehen­de Zeit­rei­hen-Workloads verfügbar.
• Da­ten­kom­pres­si­on: Apache Parquet speichert Daten spal­ten­ori­en­tiert und kom­pri­miert. Das reduziert den Spei­cher­be­darf bei großen Zeit­rei­hen­be­stän­den.
• Retention Periods: In InfluxDB 3 steuern Retention Periods, wie lange zeit­ge­stem­pel­te Daten auf­be­wahrt werden, bevor sie aus Abfragen her­aus­fal­len und später au­to­ma­tisch gelöscht werden.

Wann kommt InfluxDB zum Einsatz?

InfluxDB ist prä­de­sti­niert für An­wen­dungs­fäl­le, in denen Zeit­rei­hen ge­spei­chert, abgefragt und ana­ly­siert werden müssen. Typische Ein­satz­be­rei­che und Use Cases sind:

• Mo­ni­to­ring von Servern, Con­tai­nern und Cloud-In­fra­struk­tu­ren
• Ob­ser­va­bi­li­ty für Mi­cro­ser­vices, Ku­ber­netes und verteilte Systeme
• IoT- und IIoT-Sen­sor­da­ten
• Netzwerk- und Ap­pli­ka­ti­ons­me­tri­ken
• Log-, Trace- und Te­le­me­trie­da­ten
• En­er­gie­mo­ni­to­ring
• Pre­dic­ti­ve Main­ten­an­ce
• An­oma­lie­er­ken­nung und Pipelines für Machine-Learning

Dabei kann es sich um Millionen oder Mil­li­ar­den ein­ge­hen­der Da­ten­punk­te handeln, wie sie bei­spiels­wei­se Geräte des Internet of Things, in­dus­tri­el­le Anlagen oder wis­sen­schaft­li­che Mess­in­stru­men­te in einem kon­stan­ten Da­ten­strom liefern. Diese Daten müssen schnell ge­schrie­ben und zeitnah aus­ge­wer­tet werden.

Eine einfache Zeitreihe kann aus Da­ten­quel­le, Messwert und Zeit­stem­pel bestehen, wie diese bei­spiel­haf­te Zeitreihe zeigt:

InfluxDB un­ter­schei­det im Da­ten­mo­dell zwischen Tags und Fields:

• Tags enthalten Metadaten und werden für Filterung und Grup­pie­rung genutzt.
• Fields enthalten die ei­gent­li­chen Messwerte, die agg­re­giert, berechnet oder ana­ly­siert werden.

Im oben dar­ge­stell­ten Beispiel ist die erste Spalte also ein Tag, während die zweite ein Field ist.

InfluxDB im Vergleich zu Post­greS­QL und MongoDB

InfluxDB ersetzt weder re­la­tio­na­le Da­ten­ban­ken wie Post­greS­QL noch do­ku­men­ten­ori­en­tier­te NoSQL-Da­ten­ban­ken wie MongoDB. Die Datenbank ist auf Zeit­rei­hen­da­ten optimiert setzt im Vergleich zu anderen Da­ten­bank­sys­te­men einen anderen tech­ni­schen Schwer­punkt.

Post­greS­QL arbeitet klassisch mit Schema-on-Write. Tabellen, Spalten, Da­ten­ty­pen und Cons­traints werden definiert, bevor Daten ge­schrie­ben werden. MongoDB erlaubt fle­xi­ble­re Do­ku­ment­struk­tu­ren und wird häufig in Szenarien ein­ge­setzt, in denen Daten erst beim Lesen stärker in­ter­pre­tiert werden. InfluxDB folgt einem spe­zia­li­sier­ten Zeit­rei­hen­mo­dell: Jeder Da­ten­punkt besitzt einen Zeit­stem­pel, Tags für Di­men­sio­nen und Fields für Messwerte.

Wie funk­tio­niert InfluxDB 3?

InfluxDB 3.x basiert auf einer neuen Storage- und Query-Ar­chi­tek­tur. 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 her­vor­ge­gan­gen ist. Diese Engine wurde in Rust ent­wi­ckelt und nutzt offene Da­ten­stan­dards aus dem Apache-Ökosystem.

Die wich­tigs­ten Kom­po­nen­ten sind:

• Apache Arrow: spal­ten­ori­en­tier­tes In-Memory-Format für ana­ly­ti­sche Ver­ar­bei­tung
• Apache Parquet: spal­ten­ori­en­tier­tes Spei­cher­for­mat für per­sis­ten­te Daten
• Da­ta­Fu­si­on: SQL-Query-Engine für Planung, Op­ti­mie­rung und Aus­füh­rung von Abfragen
• Apache Arrow Flight: per­for­man­te Da­ten­über­tra­gung für ana­ly­ti­sche Workloads
• Rust: Pro­gram­mier­spra­che für eine per­for­man­te und spei­cher­si­che­re Engine

Im Folgenden werden die wich­tigs­ten Ei­gen­schaf­ten und Funk­tio­nen von InfluxDB 3.x genauer vor­ge­stellt.

Echtzeit-Analyse mit Apache Arrow

Apache Arrow ist ein zentraler Baustein von InfluxDB 3.x. Es sorgt dafür, dass Zeit­rei­hen­da­ten im Ar­beits­spei­cher spal­ten­ori­en­tiert ver­ar­bei­tet werden können. Das ist vor allem für ana­ly­ti­sche Abfragen wichtig, bei denen nur bestimmte Messwerte, Tags oder Zeit­fens­ter aus­ge­wer­tet werden. Im Un­ter­schied zu zei­len­ori­en­tier­ten Da­ten­ban­ken muss InfluxDB 3.x bei solchen Abfragen nicht ganze Da­ten­sät­ze lesen. Statt­des­sen kann die Datenbank gezielt auf die be­nö­tig­ten Spalten zugreifen. Das bringt mehrere Vorteile:

• schnel­le­re Abfragen über große Zeiträume
• ef­fi­zi­en­te­re Ag­gre­ga­tio­nen, etwa Durch­schnitts­wer­te, Ma­xi­mal­wer­te oder Per­zen­ti­le
• bessere Kom­pres­si­on ähnlicher Werte
• geringere I/O-Last bei ana­ly­ti­schen Workloads

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

Kar­di­na­li­tät ohne klas­si­sche Grenzen

Kar­di­na­li­tät be­schreibt, wie viele ein­deu­ti­ge Serien bzw. Zeit­rei­hen eine Datenbank verwaltet. In InfluxDB entsteht eine Serie aus der Kom­bi­na­ti­on von Me­a­su­re­ment, Tags und Fields. Hohe Kar­di­na­li­tät (High Car­di­na­li­ty) entsteht vor allem durch viele un­ter­schied­li­che Tag-Werte bzw. Tag-Kom­bi­na­tio­nen.

In älteren InfluxDB-Versionen konnte hohe Kar­di­na­li­tät die Per­for­mance deutlich be­ein­träch­ti­gen. Besonders dy­na­mi­sche Tags waren pro­ble­ma­tisch, zum Beispiel:

• container_id
• pod
• device_id
• request_id
• trace_id

Solche Werte ändern sich häufig und erzeugen schnell sehr viele ein­deu­ti­ge Serien. Das ist vor allem in Ku­ber­netes-, Cloud- und IoT-Um­ge­bun­gen relevant. InfluxDB 3.x wurde für solche Workloads neu aufgebaut und un­ter­stützt laut Her­stel­ler in der Variante InfluxDB 3 En­ter­pri­se Mil­li­ar­den von Serien ohne klas­si­sche Kar­di­na­li­täts­li­mits.

Für Mo­ni­to­ring und Ob­ser­va­bi­li­ty ist das ein wichtiger Vorteil: Teams können mehr tech­ni­sche Di­men­sio­nen speichern und auswerten, ohne Tags vor­schnell entfernen oder Daten stark ver­ein­fa­chen zu müssen. Trotzdem bleibt ein sauberes Schema wichtig. Tags eignen sich weiterhin für häufig ge­fil­ter­te oder grup­pier­te Di­men­sio­nen, Fields für Messwerte, die agg­re­giert oder berechnet werden.

Abfragen mit SQL und InfluxQL

InfluxDB 3.x un­ter­stützt im We­sent­li­chen zwei Ab­fra­ge­spra­chen:

• SQL für neue Projekte, ana­ly­ti­sche Abfragen und die Anbindung an be­stehen­de Tools
• InfluxQL für klas­si­sche Zeit­rei­hen­ab­fra­gen und die Migration be­stehen­der InfluxDB-1.x-Workloads

Flux spielt in InfluxDB 3.x nur noch eine Ne­ben­rol­le. Die Sprache befindet sich im Main­ten­an­ce Mode und wird in InfluxDB 3.x nicht offiziell un­ter­stützt. Das hat konkrete Kon­se­quen­zen für alle, die von InfluxDB 1.x oder 2.x migrieren: Be­stehen­de Flux-Abfragen, Tasks und Da­sh­boards lassen sich nicht au­to­ma­tisch über­neh­men. Sie müssen voll­stän­dig in SQL oder InfluxQL neu ge­schrie­ben werden.

InfluxDB 3.x setzt bei Abfragen vor allem auf SQL. Die Sprache lässt sich gut in Analyse-, BI- und Data-En­gi­nee­ring-Workflows einfügen. Eine einfache SQL-Abfrage kann zum Beispiel aktuelle CPU-Werte auslesen:

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

Da­ten­auf­nah­me mit Telegraf und In­te­gra­tio­nen

Telegraf bleibt im InfluxDB-Ökosystem wichtig. Der Agent sammelt Metriken, Events und Sen­sor­da­ten aus un­ter­schied­li­chen Quellen und schreibt sie in InfluxDB. Gerade in Mo­ni­to­ring-, IoT- und IIoT-Um­ge­bun­gen ist Telegraf weiterhin relevant, weil viele Systeme und Pro­to­kol­le über Plugins an­ge­bun­den werden können.

Der TICK-Stack aus Telegraf, InfluxDB, Chro­no­graf und Kapacitor spielt in modernen InfluxDB-3-Ar­chi­tek­tu­ren nicht mehr die gleiche zentrale Rolle wie bei älteren Versionen:

• Telegraf bleibt als Da­ten­samm­ler wichtig.
• InfluxDB 3 Explorer, Grafana und SQL-fähige BI-Tools über­neh­men heute häufiger Vi­sua­li­sie­rung, Ex­plo­ra­ti­on und Analyse.
• Chro­no­graf ist vor allem für klas­si­sche InfluxDB-1.x-Workloads relevant und in neuen InfluxDB-3-Setups meist nicht mehr die Stan­dard­ober­flä­che.

Op­ti­mie­rung von Retention und Down­sam­pling

Zeit­rei­hen­da­ten wachsen schnell. Deshalb sind Retention und Down­sam­pling zentrale Konzepte.

• Retention legt fest, wie lange Daten ge­spei­chert werden.
• Down­sam­pling reduziert ältere Daten auf geringere Auf­lö­sun­gen, zum Beispiel von Se­kun­den­wer­ten auf Minuten- oder Stun­den­ag­gre­ga­te.

In InfluxDB 3.x können hierfür SQL, externe Pipelines und die in­te­grier­te Pro­ces­sing Engine genutzt werden. Die Pro­ces­sing Engine ist eine ein­ge­bet­te­te Python-VM, die Python-Plugins ausführt, welche auf de­fi­nier­te Da­ten­ban­k­ereig­nis­se reagieren.

Für pro­duk­ti­ve Ar­chi­tek­tu­ren bedeutet das: Rohdaten können hoch­auf­lö­send auf­ge­nom­men werden, während ältere Daten ver­dich­tet oder nach de­fi­nier­ten Regeln gelöscht werden. Apache Parquet und Columnar Storage ver­bes­sern zu­sätz­lich die Spei­cher­ef­fi­zi­enz.

Use Case: AI und Pre­dic­ti­ve Main­ten­an­ce

Ein aktueller Ein­satz­be­reich für InfluxDB ist Pre­dic­ti­ve Main­ten­an­ce. Dabei werden his­to­ri­sche und aktuelle Ma­schi­nen­da­ten ana­ly­siert, um Anomalien, Ver­schleiß­mus­ter oder Aus­fall­ri­si­ken früh­zei­tig zu erkennen.

InfluxDB eignet sich für diesen An­wen­dungs­fall, weil in­dus­tri­el­le Sen­sor­da­ten fast immer Zeit­rei­hen­da­ten sind. Maschinen liefern kon­ti­nu­ier­lich Werte wie Tem­pe­ra­tur, Druck, Vibration, Drehzahl, Strom­ver­brauch, Durch­fluss oder Feh­ler­ra­ten. Diese Daten werden mit Zeit­stem­pel ge­spei­chert und können an­schlie­ßend für Modelle vor­be­rei­tet werden.

Ein typischer Ablauf sieht so aus:

1. Sensoren oder in­dus­tri­el­le Gateways erfassen Ma­schi­nen­da­ten.
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 Ab­wei­chun­gen vom Nor­mal­ver­hal­ten.
5. Da­sh­boards oder Alerting-Systeme in­for­mie­ren War­tungs­teams.

InfluxDB ist dabei nicht die voll­stän­di­ge Machine-Learning-Plattform. Die Datenbank dient als per­for­man­ter Zeit­rei­hen­spei­cher und Analyse-Layer. Besonders wichtig ist die Kom­bi­na­ti­on aus his­to­ri­schen Daten und Live-Daten. Modelle können aktuelle Messwerte mit bekannten Mustern ver­glei­chen und dadurch auf drohende Ausfälle hinweisen.