Zeitreihen-Datenbanken: Wann sie sich lohnen und wann nicht

Temperaturwerte jede Sekunde. Server-Metriken im Sekundentakt. Börsenkurse, Energieverbrauch, Maschinentelemetrie. Überall dort, wo Daten einen Zeitstempel tragen und in hoher Frequenz anfallen, stellt sich dieselbe Frage: Reicht eine relationale Datenbank — oder brauche ich etwas Spezialisiertes?

Die Antwort ist weniger eindeutig, als die Marketingseiten der Hersteller vermuten lassen.

Was Zeitreihen-Datenbanken anders machen

Eine klassische relationale Datenbank speichert Daten in Zeilen und Spalten, optimiert für Lesen, Schreiben und Verknüpfen beliebiger Datensätze. Eine Zeitreihen-Datenbank (TSDB) trifft eine bewusste Einschränkung: Sie geht davon aus, dass Daten zeitlich geordnet ankommen, selten geändert werden und fast immer in Zeitfenstern abgefragt werden.

Diese Einschränkung erlaubt Optimierungen, die relationale Datenbanken nicht bieten können:

Kompression: Zeitlich geordnete Daten lassen sich extrem effizient komprimieren. InfluxDB nutzt dafür das TSM-Format (Time Structured Merge Tree), das Schreibdurchsatz und Speichereffizienz gleichzeitig optimiert.
Schreibdurchsatz: Hunderttausende Datenpunkte pro Sekunde sind Standard. Relationale Datenbanken erreichen das nur mit erheblichem Tuning.
Retention Policies: Alte Daten automatisch löschen oder aggregieren — eingebaut, nicht nachgebaut.
Zeitbasierte Abfragen: Aggregationen über Zeitfenster (Durchschnitt der letzten 5 Minuten, Maximum pro Stunde) sind Grundoperationen, keine komplexen Queries.

InfluxDB: Der Platzhirsch

InfluxDB von InfluxData ist die bekannteste Open-Source-Zeitreihendatenbank. Sie wurde von Grund auf für zeitgestempelte Daten gebaut — kein Aufsatz auf einer bestehenden Datenbank, sondern eine eigenständige Engine.

Stärken:

Extrem hoher Schreibdurchsatz, optimiert für Sensordaten, Metriken und IoT
TSM-Format für schnelle Kompression und effiziente Speichernutzung
Flux als eigene Abfragesprache mit eingebauten ETL-Funktionen (Extract, Transform, Load)
Retention Policies und kontinuierliche Abfragen out of the box
Nahtlose Integration mit Grafana, Telegraf und dem gesamten TICK-Stack
Aktive Community und gute Dokumentation

Schwächen:

Flux ist eine eigene Sprache — kein SQL. Die Lernkurve ist real, besonders für Teams, die SQL gewohnt sind
InfluxDB 3.x hat Flux zugunsten von SQL/InfluxQL wieder abgelöst — die Abfrage-Strategie hat sich mehrfach geändert
Clustering und Hochverfügbarkeit nur in der kommerziellen Version (InfluxDB Enterprise / Cloud)
Nicht geeignet für relationale Verknüpfungen — keine JOINs, keine Fremdschlüssel
Bei komplexen analytischen Abfragen langsamer als spezialisierte Analytik-Datenbanken

Wann unbedingt nutzen:

IoT-Plattformen mit tausenden Sensoren, die im Sekundentakt schreiben
Monitoring-Stacks (Server, Container, Netzwerk) in Kombination mit Grafana
Wenn Schreibdurchsatz die kritische Anforderung ist und relationale Features nicht gebraucht werden

TimescaleDB: SQL bleibt SQL

TimescaleDB geht einen anderen Weg. Es ist eine PostgreSQL-Erweiterung — keine eigene Datenbank, sondern ein Aufsatz auf dem bewährtesten relationalen System der Welt.

Stärken:

Volle SQL-Kompatibilität — jedes PostgreSQL-Tool funktioniert, jede Bibliothek, jeder ORM
Hypertables partitionieren Zeitreihendaten automatisch, ohne dass sich die Abfragen ändern
Relationale und Zeitreihendaten in einer Datenbank — keine zweite Infrastruktur nötig
JOINs zwischen Zeitreihen und Stammdaten (z.B. Sensormetadaten) sind trivial
Compression und Retention Policies verfügbar
Bestehende PostgreSQL-Expertise im Team wird direkt genutzt

Schwächen:

Höherer Ressourcenverbrauch als native TSDBs — PostgreSQL bringt Overhead mit
Bei extremen Schreibraten (Millionen Datenpunkte pro Sekunde) nicht so performant wie InfluxDB
Skalierung über mehrere Knoten erfordert TimescaleDB Cloud oder manuelles Sharding
Nicht so schlank wie eine dedizierte TSDB — man betreibt eine vollständige PostgreSQL-Instanz

Wann unbedingt nutzen:

Wenn bereits PostgreSQL im Stack ist und Zeitreihendaten dazukommen
Wenn Zeitreihen mit relationalen Daten verknüpft werden müssen (Sensordaten + Geräteinformationen + Kundenverträge)
Wenn das Team SQL kann und keine neue Abfragesprache lernen will
Für analytische Workloads, die über reine Zeitreihen-Aggregation hinausgehen

PostgreSQL ohne Erweiterung: Oft unterschätzt

Bevor man eine spezialisierte Lösung einführt, lohnt die Frage: Reicht PostgreSQL allein?

Stärken:

Bereits vorhanden in den meisten Stacks — keine zusätzliche Infrastruktur
Partitioning nach Zeitstempel ist nativ möglich (seit PostgreSQL 10)
BRIN-Indizes sind für zeitlich geordnete Daten extrem effizient
Flexible Abfragen, JOINs, Window Functions — alles da
Kostenlos, bestens dokumentiert, riesige Community

Schwächen:

Kein automatisches Downsampling oder Retention Policies — muss selbst gebaut werden
Bei hohen Schreibraten (mehr als 10.000 Inserts pro Sekunde) wird Tuning nötig
Kompression nicht so effizient wie bei dedizierten TSDBs
Keine spezialisierten Zeitreihen-Funktionen ohne Erweiterung

Wann ausreichend:

Weniger als 10.000 Datenpunkte pro Sekunde
Zeitreihendaten sind ein Nebenschauplatz, nicht der Kern der Anwendung
Kein Budget oder Bedarf für zusätzliche Infrastruktur

MariaDB und MySQL: Möglich, aber nicht ideal

Beide können Zeitreihendaten speichern. Beide sind dafür nicht optimiert.

MariaDB bietet mit der ColumnStore-Engine eine analytische Erweiterung, die für Aggregationen über große Datenmengen besser geeignet ist als das Standard-InnoDB. Für dedizierte Zeitreihen-Workloads bleibt es aber ein Kompromiss.

MySQL ist robust und bekannt, wird bei hohen Schreibraten aber zum Flaschenhals. Partitioning ist möglich, aber weniger elegant als bei PostgreSQL.

Wann akzeptabel: Wenn MySQL/MariaDB bereits im Stack ist, die Datenmengen überschaubar sind und keine zusätzliche Datenbank eingeführt werden soll. Für dedizierte Zeitreihen-Workloads gibt es bessere Optionen.

Redis: Schnell, aber flüchtig

Redis ist keine Zeitreihen-Datenbank. Es ist ein In-Memory-Store, der mit dem RedisTimeSeries-Modul Zeitreihen-Funktionalität nachrüsten kann.

Stärken:

Extrem niedrige Latenz — Mikrosekunden statt Millisekunden
Gut für Echtzeit-Dashboards und kurzzeitige Puffer
Einfache API, schnell aufgesetzt

Schwächen:

Daten liegen im RAM — bei großen Datenmengen wird es teuer
Keine langfristige Speicherung ohne Persistenzschicht
RedisTimeSeries ist ein Zusatzmodul, nicht Teil des Kerns
Keine komplexen Abfragen, kein SQL, keine JOINs

Wann sinnvoll: Als Zwischenschicht — Echtzeit-Metriken puffern, bevor sie in eine TSDB oder relationale Datenbank geschrieben werden. Nicht als primärer Zeitreihen-Speicher.

Praxisbeispiel: Börsenkurse

Ein Anwendungsfall, der die Unterschiede greifbar macht — und der oft unterschätzt wird, was die Datenmenge und Komplexität angeht.

Was in einem Börsenkurs steckt

Ein Börsenkurs ist nicht einfach „Preis und Volumen”. Was an den Märkten als Datenstrom anfällt, umfasst mehrere Ebenen:

Trades: Einzelne ausgeführte Transaktionen — Preis, Volumen, Zeitstempel, Handelsplatz. Das ist der einfachste Datenpunkt.
Quotes (Bid/Ask): Geld- und Briefkurs mit jeweiligem Volumen — das aktuelle Angebot am Markt, aktualisiert sich oft schneller als Trades stattfinden
Spread: Differenz zwischen Bid und Ask — ein Liquiditätsindikator
OHLCV-Kerzen: Open, High, Low, Close, Volume — eine Aggregation aus Trades über ein Zeitfenster (Minute, Stunde, Tag), kein Rohdatum
Order Book Depth: Level-2-Daten mit mehreren Preisstufen auf Bid- und Ask-Seite — der vollständige Blick in die Markttiefe

Datenmengen

Die Volumina sind erheblich:

Datentyp	500 Aktien/Tag	1 Jahr	Speicher (1 Jahr, unkomprimiert)
Minutenkerzen (OHLCV)	~195.000	~49 Mio	~3 GB
Sekundenkerzen	~11,7 Mio	~2,9 Mrd	~180 GB
Tick-Daten (Trades)	5-250 Mio	1,2-62,5 Mrd	0,5-5 TB
Quotes (Bid/Ask)	50-500 Mio	12-125 Mrd	2-20 TB
Level-2 Order Book	500 Mio-5 Mrd	nicht realistisch	50-500 TB

Bei Minutenkerzen reden wir über überschaubare Mengen. Bei Tick-Daten wird es ernst. Level-2-Daten sind nur für spezialisierte Systeme realistisch speicherbar.

Berechnungen

Rohdaten allein sind wenig wert. Die typischen Berechnungen auf Börsendaten:

VWAP (Volume Weighted Average Price) — der volumengewichtete Durchschnittspreis, Standard-Benchmark
Gleitende Durchschnitte (SMA, EMA) — über 20, 50, 200 Perioden
Volatilität — Standardabweichung der Returns über ein Zeitfenster
RSI, MACD, Bollinger Bands — technische Indikatoren, die auf historischen Fenstern operieren
Korrelationen — zwischen Aktien, Sektoren, Indizes

All diese Berechnungen sind zeitfensterbasiert — genau das, wofür Zeitreihen-Datenbanken optimiert sind.

InfluxDB

# Trade-Daten schreiben (Line Protocol)
trades,symbol=AAPL,exchange=NASDAQ price=178.52,bid=178.50,ask=178.54,volume=350,trade_id="T1928374" 1711018800000000000
trades,symbol=AAPL,exchange=NASDAQ price=178.53,bid=178.51,ask=178.55,volume=120,trade_id="T1928375" 1711018800100000000

-- VWAP der letzten Stunde
SELECT sum("price" * "volume") / sum("volume") AS vwap
FROM "trades"
WHERE "symbol" = 'AAPL'
AND time > now() - 1h

-- OHLCV-Kerzen aus Tick-Daten aggregieren (5 Minuten)
SELECT
    first("price") AS open,
    max("price") AS high,
    min("price") AS low,
    last("price") AS close,
    sum("volume") AS volume
FROM "trades"
WHERE "symbol" = 'AAPL'
AND time > now() - 1d
GROUP BY time(5m)

InfluxDB spielt hier seine Stärke aus: Das Line Protocol schreibt Hunderttausende Ticks pro Sekunde. Tags (symbol, exchange) werden automatisch indiziert. Zeitbasierte Aggregationen — auch OHLCV-Kerzen aus Rohdaten — sind Einzeiler. Bei reinen Tick-Daten ohne relationale Verknüpfungen ist InfluxDB schwer zu schlagen.

TimescaleDB

-- Schema für Trade-Daten
CREATE TABLE trades (
    time        TIMESTAMPTZ NOT NULL,
    symbol      TEXT NOT NULL,
    exchange    TEXT NOT NULL,
    price       NUMERIC(12,4),
    bid         NUMERIC(12,4),
    ask         NUMERIC(12,4),
    volume      INTEGER,
    trade_id    TEXT
);

SELECT create_hypertable('trades', by_range('time'));
CREATE INDEX idx_trades_symbol ON trades (symbol, time DESC);

-- Compression nach 7 Tagen (Speicherersparnis ~90%)
ALTER TABLE trades SET (
    timescaledb.compress,
    timescaledb.compress_segmentby = 'symbol'
);
SELECT add_compression_policy('trades', INTERVAL '7 days');

-- VWAP berechnen
SELECT
    time_bucket('5 minutes', time) AS bucket,
    symbol,
    SUM(price * volume) / SUM(volume) AS vwap,
    FIRST(price, time) AS open,
    MAX(price) AS high,
    MIN(price) AS low,
    LAST(price, time) AS close,
    SUM(volume) AS volume
FROM trades
WHERE symbol = 'AAPL'
AND time > NOW() - INTERVAL '1 day'
GROUP BY bucket, symbol
ORDER BY bucket;

-- Gleitender 20-Perioden-Durchschnitt mit Window Functions
SELECT
    time_bucket('1 minute', time) AS bucket,
    AVG(price) AS close,
    AVG(AVG(price)) OVER (
        ORDER BY time_bucket('1 minute', time)
        ROWS BETWEEN 19 PRECEDING AND CURRENT ROW
    ) AS sma_20
FROM trades
WHERE symbol = 'AAPL'
AND time > NOW() - INTERVAL '1 day'
GROUP BY bucket
ORDER BY bucket;

-- Kurse mit Unternehmensdaten verknüpfen
SELECT
    c.name,
    c.sector,
    time_bucket('1 day', t.time) AS day,
    SUM(t.price * t.volume) / SUM(t.volume) AS vwap
FROM trades t
JOIN companies c ON c.symbol = t.symbol
WHERE c.sector = 'Technology'
AND t.time > NOW() - INTERVAL '30 days'
GROUP BY c.name, c.sector, day
ORDER BY day;

Der Vorteil von TimescaleDB wird bei Börsendaten besonders deutlich: Window Functions für gleitende Durchschnitte, JOINs mit Stammdaten (Unternehmen, Sektoren, Portfolios), Compression für historische Daten. Diesen JOIN und die Window Functions kann InfluxDB nicht. Wer Kursdaten nur speichern und visualisieren will, braucht sie nicht. Wer Analysen über Sektoren, Portfolios oder Korrelationen fahren will, braucht sie ständig.

PostgreSQL pur

-- Partitionierung nach Monat
CREATE TABLE trades (
    time        TIMESTAMPTZ NOT NULL,
    symbol      TEXT NOT NULL,
    price       NUMERIC(12,4),
    bid         NUMERIC(12,4),
    ask         NUMERIC(12,4),
    volume      INTEGER
) PARTITION BY RANGE (time);

CREATE TABLE trades_2026_03
    PARTITION OF trades
    FOR VALUES FROM ('2026-03-01') TO ('2026-04-01');

CREATE INDEX idx_trades_time ON trades USING BRIN (time);

Funktioniert für Minutenkerzen und moderate Datenmengen. Bei Tick-Daten mit Hunderttausenden Inserts pro Sekunde stößt PostgreSQL ohne TimescaleDB an Grenzen — Partitionen muss man selbst anlegen, Compression selbst bauen, time_bucket und FIRST/LAST-Aggregationen fehlen. Für ein Portfolio-Dashboard mit Tageskerzen absolut ausreichend. Für Echtzeit-Tick-Verarbeitung nicht.

Skalierung

Bei Börsendaten zeigt sich das Skalierungsproblem am deutlichsten:

Minutenkerzen für 500 Aktien: Jede Datenbank auf dieser Liste schafft das problemlos
Sekundenkerzen: InfluxDB und TimescaleDB ohne Tuning, PostgreSQL mit gutem Indexing
Tick-Daten: InfluxDB nativ, TimescaleDB mit Compression und Partitionierung, PostgreSQL nur mit erheblichem Aufwand
Level-2 Order Book: Spezialisierte Systeme (kdb+, Arctic), keine der hier vorgestellten Datenbanken ist dafür ausgelegt

Die Wahl hängt davon ab, auf welcher Ebene man operiert. Wer OHLCV-Kerzen für ein Dashboard braucht, überdimensioniert mit InfluxDB. Wer Tick-Daten für algorithmischen Handel verarbeitet, unterdimensioniert mit PostgreSQL.

Vergleich auf einen Blick

Kriterium	InfluxDB	TimescaleDB	PostgreSQL	MariaDB/MySQL	Redis
Schreibdurchsatz	Sehr hoch	Hoch	Mittel	Mittel	Sehr hoch
Abfragesprache	Flux / SQL (v3)	SQL	SQL	SQL	API / RedisTimeSeries
Kompression	Exzellent	Gut	Basis	Basis	Keine
Retention Policies	Eingebaut	Eingebaut	Manuell	Manuell	TTL
Relationale Daten	Nein	Ja	Ja	Ja	Nein
Lernkurve	Mittel-Hoch	Niedrig (SQL)	Niedrig	Niedrig	Niedrig
Betriebsaufwand	Eigene Infra	PostgreSQL	PostgreSQL	MySQL/MariaDB	Redis
Clustering (OSS)	Nein	Eingeschränkt	Ja	Ja	Ja
Kosten (OSS)	Kostenlos	Kostenlos	Kostenlos	Kostenlos	Kostenlos

Entscheidungshilfe

Nimm InfluxDB, wenn Schreibdurchsatz und Speichereffizienz die Hauptanforderungen sind und du keine relationalen Verknüpfungen brauchst. Typisch: Monitoring, IoT, Sensorplattformen.

Nimm TimescaleDB, wenn du bereits PostgreSQL nutzt oder Zeitreihendaten mit relationalen Daten kombinieren musst. Typisch: Unternehmensanwendungen, in denen Messdaten mit Stammdaten verknüpft werden.

Bleib bei PostgreSQL, wenn die Datenmengen überschaubar sind und Zeitreihen nur ein Teil der Anwendung. Lieber eine Datenbank gut betreiben als zwei mittelmäßig.

Nimm Redis, wenn du einen Echtzeit-Puffer brauchst — aber nicht als primären Speicher.

Vermeide MySQL/MariaDB für Zeitreihen, wenn es Alternativen gibt. Sie funktionieren, aber jede andere Option in dieser Liste ist für den Anwendungsfall besser geeignet.

Unterm Strich

Die Wahl der richtigen Zeitreihen-Datenbank ist keine Technologie-Entscheidung — sie ist eine Architektur-Entscheidung. Sie hängt davon ab, was bereits im Stack ist, wie viele Daten anfallen und ob Zeitreihen der Kern der Anwendung sind oder ein Nebenaspekt.

Die teuerste Lösung ist nicht die mit den höchsten Lizenzkosten. Es ist die, die eine zweite Infrastruktur einführt, wo eine Erweiterung der bestehenden gereicht hätte. Oder umgekehrt: die, die PostgreSQL an seine Grenzen treibt, weil jemand keine zweite Datenbank wollte.

Die richtige Frage ist nicht “Was ist die beste Zeitreihen-Datenbank?” Sondern: “Was brauche ich wirklich — und was habe ich schon?”