Datenbankmodell

Dieses Dokument beschreibt, wo und in welcher Form Studio Daten speichert. Sie verwenden es, um den Backup-Umfang zu definieren oder um direkte Abfragen durchzuführen.

Es gibt zwei Speicher

Metadaten gehen in PostgreSQL, App-Quellcode und Build-Artefakte ins Dateisystem(DATA_ROOT). Beide müssen gesichert werden, um eine Wiederherstellung zu ermöglichen — nur die DB zu sichern bedeutet, dass der App-Code fehlt; nur Dateien zu sichern bedeutet, dass die Audit-Informationen fehlen.

Speicher	Inhalt
PostgreSQL	Benutzer · App-Metadaten · Gespräche · Audit · Watcher · Skills
Dateisystem (DATA_ROOT)	Workspaces (App-Quellcode) · Build-Artefakte · Zustand

PostgreSQL ist einer von zwei Modi — gebündelter Container (Standard) oder Platform-gemeinsames PG. Siehe Umgebungsvariablen-Referenz.

---

Tabellen — 11 Stück

Gruppe	Tabelle	Inhalt
Benutzer	studio_users	Konten · Rollen (admin/builder/viewer) · Passwort-Hashes
	studio_tokens	Ausgestellte Token
Gespräche	ask_conversations	Chat-Threads
	ask_history	Ausgetauschte Nachrichten und Zeitaufwand
Watcher	watchers	Periodische Überwachungsdefinitionen und Benachrichtigungseinstellungen
	notification_seen	Benachrichtigungsbestätigungsstatus
Skills	skills	Registrierte Vor-Ort-Kenntnisse
Bereitstellung	deploy_log	Bereitstellungsverlauf
Audit · Nutzung	audit_log	Wer hat was getan
	usage_log	KI-Token-Nutzung
Schema	schema_migrations	Angewandte Migrationsnamen und Zeitstempel

watchers hieß früher flows

Am 13.07.2026 wurden die Namen vereinheitlicht (ALTER TABLE flows RENAME TO watchers, Daten beibehalten). Neue Installationen durchlaufen denselben Prozess — Migrationen zuerst mit flows erstellen, dann umbenennen — da der Migrationsverlauf Vergangenheit ist und nicht geändert wird. Wenn Sie direkte Abfragen schreiben, verwenden Sie watchers.

---

Schemaänderungen werden durch Migrationen verwaltet

Beim Start des Servers werden die .sql aus src/infra/db/migrations/ in numerischer Reihenfolge angewendet und die angewendeten Dateinamen in schema_migrations eingetragen. Bereits angewendete werden nicht erneut ausgeführt.

-- 지금 어디까지 적용됐는지
SELECT name, applied_at FROM schema_migrations ORDER BY name;

Das Schema nicht manuell ändern

Wenn schema_migrations und das tatsächliche Schema nicht übereinstimmen, schlägt die Migration beim nächsten Upgrade mit „bereits vorhanden" fehl. Der Screen-Start wird vollständig blockiert.

Erstellen Sie vor einem Upgrade zuerst ein Backup → Backup und Wiederherstellung.

---

Dateisystem — DATA_ROOT

Der Standard ist /var/lib/pp-studio. Alles Folgende wird darin gespeichert.

Inhalt	Wenn fehlt
App-Workspace (generierter Quellcode)	Apps können nicht geöffnet werden — DB enthält nur Metadaten
Build-Artefakte	Neu bauen behebt das Problem
Sitzungen · Zustand	Laufende Arbeiten gehen verloren
Gebündelte PG-Daten	Bei einer COMPOSE_PROFILES=bundled-pg-Installation ist der DB-Body hier

Mit gebündeltem PG ist DATA_ROOT gleichzeitig das DB-Backup

Im Bundle-Modus befindet sich das PostgreSQL-Datenverzeichnis auch unter DATA_ROOT. Das heißt, wenn Sie diesen Pfad übersehen, verlieren Sie DB und App-Quellcode gleichzeitig.

---

Leicht übersehene Backup-Punkte

Das muss gesichert werden	Wenn übersehen
PostgreSQL-Dump	Konten · Watcher · Gesprächsverlauf · Audit-Einträge gehen verloren
DATA_ROOT	App-Quellcode geht verloren; Apps können nicht geöffnet werden
/etc/kopens/plantpulse-studio.env	Verbindungsinformationen · Schlüssel müssen neu eingegeben werden

Testen Sie eine Wiederherstellung einmal

Der gefährlichste Zustand ist, ein Backup zu haben, aber Wiederherstellungen nie getestet zu haben. Das Verfahren finden Sie unter Backup und Wiederherstellung.

---

Zugehörige Dokumentation

• Backup und Wiederherstellung
• Umgebungsvariablen-Referenz — DB-Modi und DATA_ROOT
• Passwort · API-Schlüssel ändern — PG_PASSWORD-Rotation
• Anfangspasswort ändern — Bootstrap-Admin-Konto