Eine Spritzgussmaschine meldet jede Sekunde Temperatur, Druck und Zykluszeit. Bei 40 Maschinen sind das rund 3,5 Millionen Datensätze am Tag, nach einem Jahr weit über eine Milliarde Zeilen. Die Fragen dazu klingen harmlos: Wie hat sich die Temperatur von Maschine 17 in der letzten Woche entwickelt? Welche Anlage lief im März am häufigsten außerhalb der Toleranz? Eine gewöhnliche Datenbanktabelle wird bei solchen Abfragen irgendwann zäh, und die Festplatte füllt sich schneller als geplant.

Für genau diese Art von Daten gibt es Zeitreihendatenbanken. TimescaleDB ist eine von ihnen, mit einer Besonderheit: Sie ist keine neue Datenbank, sondern eine Erweiterung für PostgreSQL. Wer PostgreSQL kennt, arbeitet weiter mit SQL, mit denselben Werkzeugen und denselben Backups. Das ist ihr größter Vorzug, und es erklärt auch, wo sie nicht passt.

Was Zeitreihendaten von anderen Daten unterscheidet

Zeitreihendaten sind Messwerte mit Zeitstempel: Sensorwerte aus der Fertigung, Stromzähler, Serverlogs, Aktienkurse, Seitenaufrufe eines Webshops. Sie haben drei typische Eigenschaften:

• Sie kommen fast nur hinzu. Ein Messwert von gestern wird selten nachträglich geändert. Die Datenbank muss vor allem schnell schreiben.
• Abfragen beziehen sich auf Zeiträume. Gefragt wird nach „der letzten Stunde“ oder „dem Vormonat“, selten nach einem einzelnen Datensatz.
• Alte Daten verlieren an Detailwert. Sekundenwerte von vor zwei Jahren braucht kaum jemand, Tagesmittel schon.

Eine klassische relationale Datenbank – also eine, die Daten in Tabellen mit festen Spalten ablegt und über SQL abfragt – kann das grundsätzlich. Sie ist aber auf gemischte Lasten ausgelegt: Kundendaten anlegen, Bestellungen ändern, Rechnungen löschen. Bei einer einzigen, stetig wachsenden Messwerttabelle passen die Indizes irgendwann nicht mehr in den Arbeitsspeicher, Einfügen und Abfragen werden langsamer, und das Löschen alter Daten wird zur teuren Großoperation. Wie relationale und andere Datenbanktypen grundsätzlich funktionieren, erklärt unser Leitfaden zu SQL- und NoSQL-Datenbanken.

Wie TimescaleDB PostgreSQL erweitert

TimescaleDB wird als Erweiterung (Extension) in eine bestehende PostgreSQL-Installation geladen. Danach stehen zusätzliche Funktionen bereit, die normale Tabellen in Zeitreihentabellen verwandeln. Die Datenbank bleibt eine PostgreSQL-Datenbank: Abfragen, Benutzerrechte, Replikation und Werkzeuge wie pgAdmin funktionieren wie gewohnt. Mehr zu den Stärken dieser Basis lesen Sie in unserem Beitrag über PostgreSQL als Open-Source-Datenbank.

Hypertables und Chunks

Das zentrale Konzept heißt Hypertable. Nach außen sieht sie aus wie eine gewöhnliche Tabelle, Anwendungen schreiben und lesen ganz normal mit INSERT und SELECT. Intern zerlegt TimescaleDB sie automatisch in viele kleinere Teiltabellen, die Chunks, jeweils für ein Zeitintervall – etwa einen Tag oder eine Woche.

Das bringt zwei Vorteile. Beim Schreiben arbeitet die Datenbank fast immer nur im jüngsten Chunk, dessen Indizes klein bleiben und in den Arbeitsspeicher passen. Beim Lesen überspringt sie alle Chunks, die außerhalb des abgefragten Zeitraums liegen. Fragt jemand nach der letzten Woche, fasst die Datenbank die Daten aus dem Vorjahr gar nicht erst an.

-- Erweiterung einmalig in der Datenbank aktivieren
CREATE EXTENSION IF NOT EXISTS timescaledb;

-- Gewöhnliche Tabelle für Maschinendaten anlegen
CREATE TABLE messwerte (
  zeit        TIMESTAMPTZ      NOT NULL,
  maschine_id INTEGER          NOT NULL,
  temperatur  DOUBLE PRECISION,
  druck       DOUBLE PRECISION
);

-- In eine Hypertable umwandeln, ein Chunk pro Tag
-- (ab Version 2.20 alternativ direkt mit CREATE TABLE ... WITH (tsdb.hypertable))
SELECT create_hypertable(
  'messwerte',
  by_range('zeit', INTERVAL '1 day')
);

Zeitintervalle mit time_bucket

Für Auswertungen bringt TimescaleDB die Funktion time_bucket mit. Sie ordnet jeden Messwert einem festen Zeitfenster zu, ähnlich wie date_trunc in PostgreSQL, aber mit frei wählbaren Intervallen wie 15 Minuten oder 6 Stunden. Die Frage nach der Temperatur von Maschine 17 sieht damit so aus:

-- Durchschnitt und Höchstwert je 15 Minuten in den letzten 7 Tagen
SELECT time_bucket('15 minutes', zeit) AS intervall,
       avg(temperatur) AS mittel,
       max(temperatur) AS spitze
FROM messwerte
WHERE maschine_id = 17
  AND zeit > now() - INTERVAL '7 days'
GROUP BY intervall
ORDER BY intervall;

Daneben bietet die Erweiterung sogenannte Hyperfunctions, also zusätzliche Analysefunktionen, etwa für zeitgewichtete Mittelwerte bei unregelmäßig eintreffenden Messwerten oder für Kerzendiagramme (Candlesticks) mit Eröffnungs-, Höchst-, Tiefst- und Schlusskurs. Ein Teil davon liegt im separaten Paket TimescaleDB Toolkit, das zusätzlich installiert werden muss.

Speicher sparen: Kompression und Aufbewahrungsregeln

Messdaten wiederholen sich stark. Dieselbe Maschine meldet über Stunden fast dieselbe Temperatur. TimescaleDB kann ältere Chunks deshalb in ein spaltenorientiertes, komprimiertes Format umwandeln. Spaltenorientiert heißt: Statt Zeile für Zeile legt die Datenbank alle Temperaturwerte eines Abschnitts zusammen ab, was sich deutlich besser komprimieren lässt. Der Hersteller nennt für typische Daten Einsparungen von 90 Prozent und mehr. Wie viel es in Ihrem Fall tatsächlich ist, hängt stark von den Daten ab und lässt sich nur mit einem Test herausfinden.

-- Kompression aktivieren, Daten je Maschine gruppieren
ALTER TABLE messwerte SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'maschine_id'
);

-- Chunks automatisch komprimieren, sobald sie älter als 7 Tage sind
SELECT add_compression_policy('messwerte', INTERVAL '7 days');

-- Rohdaten nach zwei Jahren automatisch löschen
SELECT add_retention_policy('messwerte', INTERVAL '2 years');

Seit Version 2.18 nennt der Hersteller diese Speicherform Hypercore und führt dafür neue Funktionsnamen wie add_columnstore_policy ein. Die oben gezeigten Befehle sind seitdem als veraltet markiert, werden laut Dokumentation aber weiter unterstützt. Prüfen Sie vor dem Einsatz die Dokumentation Ihrer Version.

Die Aufbewahrungsregel ist der zweite Hebel. Weil alte Daten in eigenen Chunks liegen, löscht TimescaleDB sie, indem es ganze Teiltabellen entfernt. Das geht in Sekundenbruchteilen, während ein DELETE über Hunderte Millionen Zeilen eine normale Tabelle stundenlang beschäftigen kann.

Continuous Aggregates: Auswertungen vorab berechnen

Dashboards fragen oft immer wieder dieselben Kennzahlen ab, etwa Stunden- oder Tagesmittel. Diese jedes Mal aus den Rohdaten zu berechnen, kostet Zeit. Continuous Aggregates sind materialisierte Sichten, also gespeicherte Abfrageergebnisse, die TimescaleDB im Hintergrund laufend nachführt. Neue Messwerte fließen automatisch ein, ohne dass die gesamte Sicht neu berechnet werden muss.

-- Stundenwerte je Maschine vorab berechnen
CREATE MATERIALIZED VIEW messwerte_stuendlich
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', zeit) AS stunde,
       maschine_id,
       avg(temperatur) AS temperatur_mittel,
       max(druck) AS druck_max
FROM messwerte
GROUP BY stunde, maschine_id;

-- Sicht alle 30 Minuten für die letzten drei Tage aktualisieren
SELECT add_continuous_aggregate_policy('messwerte_stuendlich',
  start_offset      => INTERVAL '3 days',
  end_offset        => INTERVAL '1 hour',
  schedule_interval => INTERVAL '30 minutes');

In Kombination ergibt sich ein praktikables Muster: Rohdaten bleiben einige Monate vollständig erhalten und werden nach einer Woche komprimiert, die Stundenwerte bleiben dauerhaft. So beantwortet die Datenbank Fragen nach dem Vorjahr schnell, ohne jeden Sekundenwert zu speichern.

Wie schnell ist TimescaleDB wirklich?

Die ursprüngliche Fassung dieses Beitrags nannte Zahlen wie „bis zu 350-mal schnellere Abfragen“. Solche Werte stammen aus Benchmarks des Herstellers, also aus Messungen unter Bedingungen, die das eigene Produkt gut aussehen lassen. Sie sind nicht falsch, aber nicht auf jedes Projekt übertragbar.

Realistisch lässt sich sagen: Bei großen Zeitreihentabellen mit Abfragen über Zeiträume ist TimescaleDB gegenüber einer unveränderten PostgreSQL-Tabelle deutlich im Vorteil, vor allem durch das Überspringen irrelevanter Chunks, durch Kompression und durch vorab berechnete Aggregate. Bei kleinen Tabellen mit wenigen Millionen Zeilen ist der Unterschied dagegen gering; dort genügt oft ein guter Index oder die eingebaute Partitionierung von PostgreSQL. Belastbar ist nur ein eigener Test mit Ihren Daten und Ihren typischen Abfragen.

Lizenz, Betrieb und Anbieter

Ein Punkt, den Teams vor der Entscheidung kennen sollten: TimescaleDB gibt es in zwei Lizenzvarianten. Der Kern steht unter der Open-Source-Lizenz Apache 2.0. Wichtige Funktionen wie Kompression und Continuous Aggregates gehören dagegen zur Community Edition unter der Timescale License. Diese erlaubt die kostenlose Nutzung auch im Unternehmen, untersagt aber, TimescaleDB selbst als Datenbankdienst an Dritte anzubieten. Für die meisten Firmen, die die Datenbank für eigene Anwendungen nutzen, ist das unproblematisch. Es hat aber eine praktische Folge: Verwaltete PostgreSQL-Dienste großer Cloudanbieter bieten TimescaleDB teils gar nicht oder nur in der eingeschränkten Apache-Variante an. Prüfen Sie das vor der Wahl des Hostings.

Für den Betrieb gibt es drei Wege:

1. Selbst betreiben: Paketinstallation auf einem eigenen Server oder ein offizielles Docker-Image. Das ist der übliche Weg für Tests und für Unternehmen, die Daten im eigenen Rechenzentrum halten wollen.
2. Clouddienst des Herstellers: Das Unternehmen hinter TimescaleDB, das sich 2025 in Tiger Data umbenannt hat, betreibt einen eigenen Clouddienst (heute Tiger Cloud). Backups, Updates und Skalierung übernimmt der Anbieter.
3. Andere Hoster: Einige Anbieter verwalteter PostgreSQL-Datenbanken haben TimescaleDB im Programm, meist mit dem genannten Lizenzvorbehalt.

Beim Clouddienst gelten die üblichen Fragen: In welcher Region liegen die Daten, gibt es einen Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO, und wie kommen Sie wieder an Ihre Daten, wenn Sie wechseln wollen? Der letzte Punkt ist bei TimescaleDB vergleichsweise entspannt, weil die Daten in einem Standard-PostgreSQL-Format vorliegen.

TimescaleDB, KI und Vektorsuche

Der alte Text stellte TimescaleDB auch als Lösung für KI-Anwendungen vor. Das bedarf einer Einordnung. Für die Vektorsuche, die etwa bei Retrieval-Augmented Generation (RAG) eingesetzt wird – also bei Sprachmodellen, die vor der Antwort passende Dokumente aus einer Datenbank abrufen –, ist nicht TimescaleDB selbst zuständig. Die Grundlage bildet die eigenständige PostgreSQL-Erweiterung pgvector. Der Hersteller von TimescaleDB ergänzt sie um die eigene Open-Source-Erweiterung pgvectorscale für schnellere Suchindizes. Sein Projekt pgai für die Anbindung von Sprachmodellen wird dagegen seit Februar 2026 nicht mehr gepflegt.

Für Teams, die ohnehin PostgreSQL einsetzen, ist das interessant: Zeitreihen, Stammdaten und Vektoren lassen sich in einer Datenbank halten, statt drei Systeme zu betreiben. Angaben, nach denen PostgreSQL damit schneller als spezialisierte Vektordatenbanken sei, stammen aus Herstellermessungen und hängen stark von Datenmenge und Konfiguration ab.

Für wen sich TimescaleDB lohnt

Gut geeignet ist TimescaleDB, wenn mehrere dieser Punkte zutreffen:

• Es fallen laufend Messwerte an, etwa aus Maschinen, Gebäudetechnik oder IoT-Anwendungen in der vernetzten Fabrik, und die Tabellen wachsen in den Bereich von Hunderten Millionen Zeilen.
• Das Team kennt PostgreSQL und SQL und möchte Messdaten mit Stammdaten – Maschinen, Standorte, Kunden – in einer Abfrage verknüpfen.
• Auswertungen laufen über Zeiträume, und alte Daten sollen automatisch verdichtet oder gelöscht werden.

Weniger passend ist sie, wenn die Datenmenge klein bleibt, wenn reine Metriken für die Serverüberwachung gesammelt werden (dafür sind Prometheus und verwandte Werkzeuge verbreitet) oder wenn sehr große Analysen über viele Spalten im Vordergrund stehen, für die spaltenorientierte Analysedatenbanken wie ClickHouse gebaut sind. Kommen die Daten aus vielen Quellen gleichzeitig, steht vor der Datenbank oft eine Streaming-Plattform wie Apache Kafka, die die Messwerte puffert und verteilt.

Unsere Einschätzung: Für die meisten mittelständischen Projekte mit Sensor- oder Betriebsdaten ist TimescaleDB eine nüchterne, gute Wahl, gerade weil es keine neue Technologie ins Haus bringt. Überschätzt wird der Geschwindigkeitsgewinn aus Herstellerbenchmarks, unterschätzt wird der Wert von Kompression und Aufbewahrungsregeln, die den Speicherbedarf auf Jahre planbar machen. Wer Datenarchitektur und Auswertung gemeinsam angehen will, findet bei unserer Beratung und den Seminaren zu Big Data und Analytics einen Einstieg.

Häufige Fragen zu TimescaleDB

Müssen Anwendungen für TimescaleDB umgeschrieben werden?

Meist nicht. Eine Hypertable verhält sich für Anwendungen wie eine gewöhnliche PostgreSQL-Tabelle. Treiber, ORMs und Abfragen bleiben gleich. Neu sind vor allem die Verwaltungsbefehle für Hypertables, Kompression und Aggregate.

Ist TimescaleDB kostenlos?

Die Erweiterung lässt sich selbst betrieben kostenlos nutzen, auch mit den Funktionen der Community Edition, solange Sie TimescaleDB nicht selbst als Datenbankdienst für Dritte anbieten. Kosten entstehen für Server und Betrieb oder für den Clouddienst des Herstellers.

Ab welcher Datenmenge lohnt sich der Umstieg?

Eine feste Grenze gibt es nicht. Ein Anhaltspunkt: Solange eine Tabelle wenige Millionen Zeilen hat und Abfragen schnell genug sind, reicht PostgreSQL allein. Wächst sie täglich um Millionen Zeilen oder wird das Löschen alter Daten zum Problem, lohnt ein Test.

Kann TimescaleDB über mehrere Server verteilt werden?

Eine frühere Funktion für verteilte Hypertables über mehrere Knoten hat der Hersteller wieder eingestellt. Heute skaliert TimescaleDB vor allem auf einem Server, ergänzt um Lesereplikate und, im Clouddienst, um die Auslagerung alter Daten in günstigeren Objektspeicher.