← Alle Insights

Datenbank für Marktdaten: TimescaleDB, ClickHouse, kdb+.

CSV reicht für die ersten drei Strategien. Parquet reicht für die nächsten dreißig. Irgendwann reicht es nicht mehr — und die Frage ist, welche Datenbank den nächsten Schritt trägt, ohne dass Sie in zwei Jahren wieder migrieren müssen.

Wann CSV und Parquet aufhören zu reichen.

Drei Signale, dass Sie eine echte Datenbank brauchen:

Die drei Hauptkandidaten.

TimescaleDB

PostgreSQL-Extension. Behält die gesamte Postgres-Welt (SQL, Joins, JSON, Tooling) und fügt Hypertables hinzu — automatisch nach Zeit partitionierte Tabellen mit optimierter Insert- und Query-Performance. Mein Default für die meisten Setups unter 1 TB Daten.

ClickHouse

Spalten-orientierte OLAP-Datenbank. Brutal schnell bei Aggregations-Queries über riesige Zeiträume, exzellente Kompression (oft 10×–20× gegenüber CSV). Schwächer bei Einzel-Row-Updates und komplexen Joins. Sweet-Spot: Sie wollen Milliarden Ticks speichern und in Sekunden gruppieren.

kdb+

Der Industrie-Standard bei großen Banken und HFT-Häusern. Eigene Sprache (q), extreme Performance bei Time-Series-Joins (asof-Join), winziger Footprint. Lizenz ist teuer, Lernkurve steil. Außerhalb institutioneller Setups selten die richtige Wahl.

Vergleich auf einen Blick.

Kriterium          TimescaleDB        ClickHouse          kdb+
-----------------  -----------------  ------------------  ------------------
Lizenz             Apache 2 / TSL     Apache 2            Kommerziell
Sprache            SQL (Postgres)     SQL (Dialekt)       q (proprietär)
Insert-Perf        ~500k rows/sec     ~1–2M rows/sec      ~5M+ rows/sec
Query-Perf agg.    sehr gut           exzellent           exzellent
Joins (relational) exzellent          okay                okay (asof: top)
Lernkurve          flach (SQL)        mittel              steil
Ecosystem          riesig (Postgres)  groß                klein, exklusiv
Kosten Self-host   0                  0                   ~100k €/Jahr Enterp.
Cloud-Angebot      Timescale Cloud    ClickHouse Cloud    KX Insights

Schema-Empfehlungen.

OHLCV-Bars

CREATE TABLE bars (
    ts          TIMESTAMPTZ NOT NULL,
    symbol      TEXT        NOT NULL,
    timeframe   TEXT        NOT NULL,   -- '1m', '5m', '1h', '1d'
    open        DOUBLE PRECISION,
    high        DOUBLE PRECISION,
    low         DOUBLE PRECISION,
    close       DOUBLE PRECISION,
    volume      DOUBLE PRECISION
);
SELECT create_hypertable('bars', 'ts', chunk_time_interval => INTERVAL '7 days');
CREATE UNIQUE INDEX ON bars (symbol, timeframe, ts DESC);

Tick-Daten

Für Ticks lohnt eine schlankere Tabelle und aggressivere Chunks (z. B. 1 Tag), damit Compression später besser greift:

CREATE TABLE ticks (
    ts      TIMESTAMPTZ NOT NULL,
    symbol  TEXT        NOT NULL,
    price   DOUBLE PRECISION,
    size    DOUBLE PRECISION,
    side    SMALLINT     -- 1 = buy, -1 = sell, 0 = unknown
);
SELECT create_hypertable('ticks', 'ts', chunk_time_interval => INTERVAL '1 day');
ALTER TABLE ticks SET (timescaledb.compress, timescaledb.compress_segmentby = 'symbol');
SELECT add_compression_policy('ticks', INTERVAL '7 days');

Orderbook-Snapshots

Hier wird es interessant: man kann jeden Level (L1–L10) als eigene Spalte führen, oder die Tiefe als JSON/Array. Für ClickHouse sind Arrays effizient, für Timescale ist das schlanke „eine Zeile pro Level"-Schema robuster:

CREATE TABLE book_levels (
    ts      TIMESTAMPTZ NOT NULL,
    symbol  TEXT        NOT NULL,
    side    SMALLINT,    -- 1 = bid, -1 = ask
    level   SMALLINT,    -- 0 = best, 1 = next, ...
    price   DOUBLE PRECISION,
    size    DOUBLE PRECISION
);
SELECT create_hypertable('book_levels', 'ts');

Continuous Aggregates: das unterschätzte Feature.

Timescale kann aus Ticks oder 1m-Bars automatisch höhere Timeframes materialisieren — ohne dass Sie selbst Cron-Jobs schreiben:

CREATE MATERIALIZED VIEW bars_5m
WITH (timescaledb.continuous) AS
SELECT
    time_bucket('5 minutes', ts) AS bucket,
    symbol,
    first(price, ts)  AS open,
    max(price)        AS high,
    min(price)        AS low,
    last(price, ts)   AS close,
    sum(size)         AS volume
FROM ticks
GROUP BY bucket, symbol;

SELECT add_continuous_aggregate_policy('bars_5m',
    start_offset => INTERVAL '1 day',
    end_offset   => INTERVAL '5 minutes',
    schedule_interval => INTERVAL '5 minutes');

Das ersetzt 80 % der Resampling-Pipelines, die ich in den letzten Jahren bei Kunden in Pandas gesehen habe.

Wann kdb+ wirklich sinnvoll ist.

Klare Antwort: wenn Sie institutionell sind, mehr als ~100 GB Daten pro Tag verarbeiten, asof-Joins (Quote zum letzten Trade) zum Kerngeschäft gehören und Sie bereits Personal haben, das q schreiben kann. Für Privatanleger, Family Offices unter ~500 Mio. AuM oder die meisten Quant-Boutiquen ist TimescaleDB oder ClickHouse die wirtschaftlich vernünftigere Wahl.

kdb+ hat eine Personal Edition (kdb+ Personal), die für Hobby-Forschung reicht — aber kommerzielle Nutzung ist explizit ausgeschlossen. Wer „mal kdb+ testen" will, ist mit dieser Edition genau richtig, sollte aber wissen, dass der Schritt zur Enterprise-Lizenz ein sechsstelliger Jahresvertrag ist.

Backups für Marktdaten.

Drei Ebenen, die ich für ernsthafte Setups empfehle:

Letzteres klingt paranoid, ist aber günstig. 1 TB Glacier kostet wenige Euro pro Monat. Wer einmal eine kaputte Hypertable nach einem Version-Upgrade gesehen hat, macht das nie wieder ohne.

Kostenstrukturen.

Mein Default-Stack.

Für 90 % der Kunden, mit denen ich arbeite: TimescaleDB self-hosted auf einem Hetzner- oder Bare-Metal-Server, Streaming-Replik auf zweitem Host, tägliche Snapshots nach S3. Wenn Aggregations-Queries über mehrere Jahre Ticks zum Engpass werden, kommt ClickHouse für genau diese Workload daneben — nicht als Ersatz, sondern als spezialisierter Analytics-Layer. kdb+ habe ich in den letzten Jahren bei genau zwei Mandanten eingesetzt; beide haben es gebraucht.

Sie wollen Ihre Marktdaten endlich aus dem CSV-Chaos in eine saubere Datenbank bringen? Erstgespräch buchen — wir wählen das System, das zu Ihrem Volumen und Ihrem Team passt.