22 lines
1.0 KiB
Markdown
22 lines
1.0 KiB
Markdown
# 005 – SQLite als Datenbank (vorerst)
|
||
|
||
**Status:** accepted
|
||
|
||
**Kontext.** Einzelne Instanz, ein Nutzer, kleine Datengröße im KB/MB-Bereich
|
||
(ein Gericht-Eintrag ~ 10 Zeilen + Historik). Backup-Pipeline (borgbackup)
|
||
deckt bereits das gesamte Homelab ab. Es gibt keinen Bedarf an HA (High
|
||
Availability), Multi-Node oder komplexen Transaktionen.
|
||
|
||
**Entscheidung.** **SQLite** via Doctrine (Symfony unterstützt SQLite natively
|
||
seit 4.x mit guter Migrations-Schicht). Ein Dateivolumen (`app.db`) im Docker-Stack.
|
||
|
||
**Konsequenzen.**
|
||
- + Extrem einfach: keine DB-Instanz, kein User/Passwort, kein Netzwerk.
|
||
- + Snapshot-Backup via `cp app.db` oder Borg direkt.
|
||
- + Kein `docker-compose`-DB-Service (einer weniger Container).
|
||
- + SQLite hat eine saubere WAL-Modus-API, die für die Zugriffsrate ausreicht.
|
||
- − Keine Remote-Replikation, kein Replikations-Setup (hier erwünscht).
|
||
- − Falls wir später mehrere Instanzen brauchen, wäre Postgres die Alternative –
|
||
aber das ist nicht aktuell (viele Homelab-Instanzen nutzen ja Postgres,
|
||
wenn sie es brauchen).
|