# 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 über das eingebaute **`node:sqlite`** im WAL-Modus, eine Datei im
Docker-Volume `abdulive-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.
- `node:sqlite` ist synchron (`DatabaseSync`), was den Code im Ingest erheblich
  vereinfacht - keine Race Conditions zwischen Ereignisverarbeitung und
  Schreibvorgang.
- Es ist **in Node 24 enthalten**: keine native Abhaengigkeit, kein node-gyp,
  keine Prebuild-Suche im Docker-Build. Siehe Nachtrag 2 in ADR-0001.
- 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.