---
title: "Datenbank"
description: "Die Metadaten-Datenbank (Meta-DB) speichert, was sich nicht aus Dateien ableiten lässt: standardmäßig SQLite, für ein Team via META_DB_URL auch Postgres."
---

# Datenbank

In Notarium sind Notizen Dateien, und Suchindex und Graph werden aus ihnen neu aufgebaut. Ein Teil des Zustands lässt sich jedoch **nicht aus Dateien ableiten**: Dafür gibt es eine eigene Metadaten-Datenbank (Meta-DB). Standardmäßig ist das eine SQLite-Datei im Datenverzeichnis — `<DATA_DIR>/meta.db`; die Variable `META_DB_URL` brauchst du nur, um auf ein externes Postgres zu verweisen.

## Was die Metadaten-Datenbank speichert

| Daten | Warum nicht aus Dateien |
|---|---|
| Notiz-Identifikatoren | Das Register `notarium-id` ↔ Pfad: es übersteht Verschieben und Umbenennen. |
| Versionsverlauf | Das Revisionsprotokoll (Versions-Snapshots, Herkunft einer Bearbeitung) führt die App selbst, nicht git. |
| Benutzer und Zugriffe | Konten, Rollen, Mitgliedschaften, Tokens. |
| Umbenennungsverlauf | Aliasse für die alten Slugs von Spaces und Projekten — damit frühere Adressen weiterhin aufgelöst werden. |

Nichts davon lässt sich allein aus `.md`-Dateien rekonstruieren — deshalb gehört die Metadaten-Datenbank immer ins [Backup](/docs/self-hosting/backup/). Ein Register der Spaces liegt zwar ebenfalls in dieser Datenbank, ist dort aber abgeleitet: Die Identität eines Space steckt in einer Markerdatei in seinem Wurzelverzeichnis und wird per Scan wiederhergestellt ([File-first](/docs/concepts/file-first/)). Die abgeleiteten Indizes der Engine (`<DATA_DIR>/engine`) werden nach einem Verlust beim nächsten Start einfach aus den Dateien neu aufgebaut.

Mehr zu den Versionen selbst und ihrer Herkunft findest du unter [Konzepte: Versionierung](/docs/concepts/versioning/).

## Schema und Migrationen

Das Schema der Metadaten-Datenbank verwaltet die Anwendung selbst: Migrationen werden **beim Start** angewendet, einen eigenen Befehl dafür gibt es nicht. Die Datenbank selbst führt ein Migrationsjournal mit den auf sie angewendeten Migrationen — daran erkennt ein Build, womit er es zu tun hat.

Beim Start werden genau drei Zustände akzeptiert:

- **eine leere Datenbank** — das Basisschema wird angelegt, der Journaleintrag in derselben Transaktion geschrieben;
- **eine Datenbank, deren Journal ein exaktes Präfix des erwarteten ist** — Versionen, Namen und Prüfsummen werden abgeglichen, anschließend wird der fehlende Rest angewendet;
- **eine nicht leere Datenbank ohne Journal** — der Start **bricht ab (fail closed)**, noch vor jeder Schemaänderung und jeder Abfrage der Anwendung.

Der letzte Fall ist Absicht. Ein Build rät nicht, welche Version eine Datenbank hat, die er nicht kennt, und schreibt den Journaleintrag auch nicht eigenmächtig: Das würde die Daten stillschweigend beschädigen. Wenn du genau so eine Datenbank vor dir hast — etwa eine Instanz, die älter ist als das Basisschema —, aktualisiere und prüfe sie zuerst mit dem regulären Verfahren ihrer eigenen Version und führe sie erst dann über diese Grenze.

> [!important] Rollback heißt: aus einem Backup wiederherstellen
> Der Mechanismus für ein Rollback von Daten in Notarium ist ein verifiziertes Archiv, keine rückwärts laufenden SQL-Migrationen. Erstelle und prüfe ein Backup **vor** dem Upgrade: [Backup und Wiederherstellung](/docs/self-hosting/backup/).

## SQLite (Standard)

Ohne Konfiguration: Standardmäßig ist die Meta-DB `sqlite:<DATA_DIR>/meta.db`, also eine Datei auf dem `/data`-Volume. Es braucht keinen separaten Dienst, und es ist nichts einzustellen. Das reicht für eine persönliche Instanz und ein kleines Team in **einem einzigen** Container.

## Postgres (für Team und geteilten Zustand)

Um den Zustand aus dem Container herauszulösen — für geteilten Speicher, Ausfallsicherheit oder Wartung — verweise auf Postgres:

```bash
# .env
META_DB_URL=postgres://user:pass@db:5432/notarium
```

Postgres brauchst du, wenn der Zustand unabhängig vom Lebenszyklus des Containers bestehen muss. Die Notizen selbst bleiben dabei weiterhin Dateien unter `<DATA_DIR>/spaces` — nur das, was sich nicht aus ihnen ableiten lässt, wandert in die DB.

> [!important] Der Modus `password` ist auf die Metadaten-Datenbank angewiesen
> Im Modus `AUTH_MODE=password` wird die Metadaten-Datenbank für Konten und Tokens benötigt — und sie ist standardmäßig bereits vorhanden (SQLite im Datenverzeichnis). `META_DB_URL` musst du nicht extra setzen; du gibst es nur an, um auf Postgres umzuziehen. Nur `AUTH_MODE=none` funktioniert ohne Metadaten-Datenbank. Siehe [Authentifizierung](/docs/self-hosting/authentication/).

> [!note] Eine einzige Instanz
> Den Zustand nach Postgres auszulagern, ermöglicht für sich genommen noch keine horizontale Skalierung: Notarium läuft als eine einzige Instanz, mehrere Instanzen hinter einem Load Balancer werden nicht unterstützt (siehe [Produktion](/docs/self-hosting/production/)).