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:
- Concurrent Access: Backtest, Live-Bot und Forschungs-Notebook wollen gleichzeitig auf dieselben Daten zugreifen. Parquet-Files mit Lock-Files sind eine schlechte Konkurrenz-Strategie.
- Real-Time-Append: Live-Ticks landen sekündlich an. Parquet umschreiben für jeden Append ist absurd, Append-only-Parquet (mit Partitionen) geht, ist aber Bastelei.
- Skalierung über RAM hinaus: Sobald Sie Multi-Asset-Studien auf 10+ Jahre Tick-Daten fahren, geht Pandas in den Swap. Eine Spalten-DB liefert dieselbe Query in Sekunden statt Minuten.
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:
- Streaming-Replikation: Postgres / TimescaleDB Standby-Replik auf zweitem Host. Bei Ausfall: Promote, weiter geht's.
- Tägliche Snapshots:
pg_basebackupoder Filesystem-Snapshot, verschlüsselt nach S3 / Backblaze. Retention 30 Tage. - Cold-Storage der Rohdaten: alle Ticks, die je in die DB geflossen sind, parallel als Parquet in S3 Glacier. Falls DB-Schema fundamental kaputt geht, können Sie aus Parquet neu aufbauen.
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.
- TimescaleDB Self-hosted: kostenlos (Apache 2 + TSL für Enterprise-Features wie Compression). Server: 50–200 €/Monat je nach Volumen.
- Timescale Cloud: ab ~100 €/Monat, skaliert mit Compute und Storage. Sinnvoll, wenn Sie keinen DBA haben.
- ClickHouse Self-hosted: kostenlos, Apache 2. Ressourcen-hungriger als Postgres.
- ClickHouse Cloud: ab ~200 €/Monat für ernsthafte Workloads.
- kdb+ Personal: kostenlos, nicht-kommerziell.
- kdb+ Enterprise: realistisch ab ~100 k €/Jahr, häufig deutlich mehr.
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.