# ADR-0002: SQLite statt Postgres

**Status:** akzeptiert · **Datum:** 2026-09-09

## Kontext

Mehrere Prozesse schreiben und lesen dieselben Daten. Datenvolumen: bei ~10
Zuschauern und 4 Streams pro Woche etwa 20.000 Chat-Nachrichten und 15.000
Viewer-Samples pro Monat — wenige MB.

## Entscheidung

SQLite (`better-sqlite3`) im WAL-Modus, eine Datei unter `data/db/`.

## Begründung

- Kein Server, kein Docker, kein Zustand außerhalb einer Datei. Backup ist ein
  Dateikopie-Vorgang (`VACUUM INTO`).
- WAL erlaubt beliebig viele gleichzeitige Leser neben einem Schreiber. Genau
  unsere Topologie: Der Ingest schreibt, alle anderen lesen.
- `better-sqlite3` ist synchron, was den Code im Ingest erheblich vereinfacht —
  keine Race Conditions zwischen Event-Verarbeitung und Schreibvorgang.
- Die Datenmenge ist um Größenordnungen von SQLites Grenzen entfernt.

## Konsequenzen

- **Nur ein schreibender Prozess.** Der Ingest ist der einzige Schreiber für
  `events`, `chat_messages`, `viewer_samples`, `streams`, `user_streams`.
  Andere Apps schreiben ausschließlich in ihre eigenen Tabellen (`clips`,
  `posts`, `redemptions`, `raids`). Diese Aufteilung ist verbindlich.
- Schreibende Zugriffe immer in Transaktionen bündeln, `busy_timeout` auf 5000 ms.
- Migration auf Postgres wäre nötig, wenn das Dashboard je remote laufen soll.
  Steht nicht an; die Repository-Schicht in `packages/db` kapselt SQL genug,
  dass es machbar bliebe.