Integrierte oder externe Datenbank? So wählen Sie eine Datenbankarchitektur für eine selbstgehostete Anwendung

Beginnen Sie mit der Betriebsgrenze, nicht mit der scheinbar ausgefeilteren Option

Bei einer Docker-basierten Anwendung bedeutet eine integrierte Datenbank üblicherweise, dass die Anwendung und ihr unterstützter Datenbankdienst als Teil derselben Compose-Anwendung definiert sind. Sie können in getrennten Containern laufen, während die Datenbank ihre Daten in einem Docker-Volume speichert. Eine externe Datenbank ist ein separat betriebener Datenbankdienst, den die Anwendung über eine konfigurierte Verbindung erreicht.

Keine der beiden Varianten ist grundsätzlich zuverlässiger, sicherer oder professioneller. Die hilfreiche Frage lautet: Welches Team verantwortet die vollständige Servicegrenze, und kann dieses Team deren Abhängigkeiten, Änderungen und Wiederherstellungsverfahren gut betreiben?

Eine integrierte Datenbank kann die risikoärmere Auslegung sein, wenn die Anwendung sie offiziell unterstützt und ein kleines Team einen abgegrenzten Stack mit einem klaren Lebenszyklus benötigt. Eine separate Datenbank kann passend sein, wenn die Anwendungsdokumentation sie verlangt, wenn zugelassene Workloads tatsächlich einen gemeinsam genutzten Dienst benötigen oder wenn ein Datenbank- beziehungsweise Infrastrukturteam bereits definierte Betriebsverfahren für diesen Dienst hat.

• Wählen Sie die kleinste Betriebsgrenze, die die dokumentierten Anforderungen der Anwendung erfüllt.
• Setzen Sie „extern“ nicht mit ausfallsicher gleich und „integriert“ nicht mit entbehrlich.
• Treffen Sie die Entscheidung pro Anwendung und pro dokumentiertem Bereitstellungsmodell, statt eine Regel für alle Workloads zu übernehmen.

Prüfen Sie das unterstützte Bereitstellungsmodell der Anwendung, bevor Sie die Infrastruktur entwerfen

Die Dokumentation der Anwendung selbst ist maßgeblich dafür, ob sie eine integrierte Datenbank, eine externe Datenbank oder beides unterstützt. Erledigen Sie diese Prüfung, bevor Sie einen Host bereitstellen oder Produktionsdaten migrieren. Eine technisch mögliche Verbindungszeichenfolge belegt nicht, dass ein Bereitstellungsmuster bei Upgrades, Migrationen oder der Wiederherstellung nach Vorfällen unterstützt wird.

Prüfen Sie die dokumentierten Anforderungen an Datenbank-Engine und Version. Prüfen Sie dann genau, wie die Anwendung Verbindungseinstellungen erhält, wie sie Schemamigrationen durchführt, ob sie eine bestimmte Datenbankerweiterung oder einen Initialisierungsschritt erwartet und ob sie Annahmen zur Hochverfügbarkeit oder zu Backups dokumentiert.

Auch das Startverhalten ist wichtig. In Compose bedeutet der Start einer Abhängigkeit allein nicht, dass sie bereits Datenbankverbindungen akzeptieren kann. Docker dokumentiert, dass Compose normalerweise darauf wartet, dass ein abhängiger Container läuft, nicht darauf, dass er bereit ist. Wenn die Anwendungsbereitstellung dies vorsieht, können ein Datenbank-Health-Check und eine service_healthy-Abhängigkeitsbedingung verhindern, dass eine Anwendung ihre erste Verbindung zu früh versucht.

• Unterstützte Datenbank-Engine, Hauptversion und erforderliche Erweiterungen.
• Unterstützte Verbindungseinstellungen und ob TLS, Zertifikate oder Netzwerkregeln dokumentierte Anforderungen sind.
• Migrationsbefehl, Zeitpunkt der Migration, Verhalten bei Fehlern und Hinweise zum Rollback.
• Unterstützter Upgradepfad für Anwendung und Datenbank.
• Vom Anwendungsanbieter veröffentlichte Hinweise zu Backup, Wiederherstellung und Hochverfügbarkeit.
• Erwartungen an Startreihenfolge und Health-Checks.

Erfassen Sie den vollständigen Datenpfad: Die relationale Datenbank ist selten das gesamte System

Identifizieren Sie vor der Wahl einer Datenbankarchitektur jede Komponente, die persistenten oder sicherheitskritischen Zustand speichert. Die relationale Datenbank kann für Anwendungsdatensätze maßgeblich sein, doch dieselbe Anwendung kann außerdem von Dateispeicher, Objektspeicher, einem Cache, einem Suchindex, einer Queue, Konfigurationsdateien und Secrets abhängen. Für jede dieser Komponenten können andere Modelle für Persistenz, Backup und Wiederherstellung gelten.

Docker Compose unterscheidet Ressourcen wie Services, Volumes, Configs und Secrets. Diese Unterscheidung ist betrieblich wichtig. Ein benanntes Docker-Volume kann einen entfernten Container überdauern und trennt damit den Lebenszyklus eines Datenbankcontainers vom Lebenszyklus der Datenbankdaten. Es belegt jedoch nicht, dass das bloße Kopieren eines laufenden Datenbankdatenverzeichnisses ein konsistentes Datenbankbackup ergibt.

Erstellen Sie ein Inventar, das für jeden Datentyp die maßgebliche Quelle benennt. Dies ist die Grundlage für einen Wiederherstellungsplan, einen Migrationsplan und eine korrekte Antwort auf die Frage: „Was verlieren wir, wenn diese Komponente nicht verfügbar ist oder von einem früheren Zeitpunkt wiederhergestellt wird?“

• Relationale Datenbank: transaktionale Anwendungsdatensätze, Identitäten, Einstellungen oder Metadaten, soweit dokumentiert.
• Datei- oder Objektspeicher: Uploads, Anhänge, erzeugte Exporte, Medien oder Dokumente, sofern verwendet.
• Cache: klären, ob er sicher neu aufgebaut werden kann oder Zustand enthält, der die Wiederherstellung beeinflusst.
• Suchindex oder Vektorspeicher: klären, ob er maßgeblich ist oder aus einer anderen Quelle neu aufgebaut werden kann.
• Queue- oder Workflow-Zustand: feststellen, ob ausstehende Arbeit erhalten werden muss und wie sie wiederhergestellt wird.
• Anwendungskonfiguration und Secrets: die Konfiguration aufbewahren, die zum erneuten Verbinden von Komponenten sowie zum Entschlüsseln oder Zugreifen auf geschützte Daten erforderlich ist.

Wann eine integrierte Datenbank die sinnvolle Wahl ist

Eine integrierte Datenbank ist oft geeignet, wenn sie Teil einer offiziell dokumentierten Anwendungsbereitstellung ist, der Workload klar abgegrenzt ist und dasselbe Team Anwendung und Datenbank als einen Service betreiben kann. Sie begrenzt die Zahl unabhängiger Systeme, die gemeinsam konfiguriert, überwacht, geändert und wiederhergestellt werden müssen.

Diese Wahl bedeutet nicht, die Datenbank als unwichtigen Sidecar zu behandeln. Sie benötigt weiterhin persistenten Speicher, Zugangsdaten, Backup-Abdeckung, Überwachung des Speicherwachstums, einen dokumentierten Upgradepfad und Wiederherstellungstests. Ihr Vorteil ist eine einfachere Verantwortungsgrenze, nicht das Fehlen von Datenbankbetrieb.

Für ein kleines technisches Team kann dies leichter zu überblicken sein als ein entfernter Dienst mit getrennten Netzwerkwegen, Firewallregeln, Kontoverwaltung und Wartungsfenstern. Halten Sie die Grenze klar: Anwendungsstack und Datenbank werden als abgestimmtes System bereitgestellt, aktualisiert und wiederhergestellt.

• Der Anbieter dokumentiert die integrierte Bereitstellung als unterstützt.
• Ein Team verantwortet sowohl den Lebenszyklus der Anwendung als auch den der Datenbank.
• Ein dedizierter Datenbankdienst ist nicht durch Richtlinien, Architektur oder Anbieterhinweise erforderlich.
• Das Team kann die Datenbank und jeden zugehörigen maßgeblichen Speicher sichern und wiederherstellen.
• Der Stack verfügt über ein klares Modell für persistenten Speicher, statt sich auf das flüchtige Container-Dateisystem zu verlassen.

Wann eine externe Datenbank gerechtfertigt ist

Nutzen Sie eine separat betriebene Datenbank, wenn es eine konkrete Anforderung gibt und nicht lediglich eine Präferenz für Trennung. Gültige Gründe sind eine dokumentierte Anwendungsarchitektur, ein bestehendes Datenbankteam mit klaren Verantwortlichkeiten und Wiederherstellungsverfahren oder ein tatsächlicher Bedarf, dass mehrere zugelassene Workloads einen gemeinsam genutzten Datenbankdienst verwenden.

Ein gemeinsam genutzter Dienst sollte nicht zu einer beiläufigen Sammelstelle für unzusammenhängende Anwendungen werden. Jeder Workload benötigt weiterhin definierte Datenbankrollen, Zugriffsgrenzen, abgestimmte Wartung und eine Entscheidung für die Wiederherstellung. Das Teilen einer Engine oder eines Clusters beseitigt nicht die Notwendigkeit, Zugangsdaten zu isolieren und festzulegen, wer Änderungen vornehmen darf.

Eine spezialisierte Datenbankplattform oder ein internes Infrastrukturteam kann besser passen, wenn die Organisation bereits über Fähigkeiten, Kontrollen und ein Servicemodell für deren Betrieb verfügt. Dieses Team sollte benennen können, wer Zugriffe, Upgrades, Backup-Verifizierung, Wiederherstellung, Kapazität und Reaktion auf Vorfälle verwaltet. Wenn diese Antworten unklar sind, verlagert das Verschieben der Datenbank möglicherweise nur Arbeit ohne Verantwortliche.

• Der Anwendungsanbieter dokumentiert eine externe Datenbank als erforderlich oder für die beabsichtigte Bereitstellung unterstützt.
• Ein namentlich benanntes Team verantwortet den Datenbankbetrieb und verfügt über ein getestetes Wiederherstellungsverfahren.
• Für Netzwerkkonnektivität, Authentifizierung und Firewallverwaltung gibt es klare Verantwortliche.
• Der Bedarf an einem gemeinsam genutzten Dienst ist real, genehmigt und mit einer angemessenen Zugriffstrennung vereinbar.
• Die Wartung von Anwendung und Datenbank kann abgestimmt werden, einschließlich Schemamigrationen und Upgrades auf Hauptversionen.

Verwechseln Sie Trennung nicht mit Ausfallsicherheit

Eine externe Datenbank führt eine zusätzliche Servicegrenze ein. Die Anwendung hängt nun von Netzwerkerreichbarkeit, Namensauflösung, Firewall- und Routingregeln, Zugangsdaten, Authentifizierungsregeln, der Datenbank-Listener-Konfiguration und dem Wartungsplan des externen Dienstes ab. Jede dieser Abhängigkeiten benötigt einen Verantwortlichen und einen Reaktionsweg für Vorfälle.

Für PostgreSQL wird insbesondere die Freigabe von TCP/IP-Verbindungen durch Einstellungen wie listen_addresses gesteuert, während die Client-Authentifizierung kontrolliert, wer sich verbinden darf. PostgreSQL verwendet außerdem Rollen für die Rechteverwaltung, und der aktive Datenbankbenutzer bestimmt den Zugriff auf Datenbankobjekte. Dies sind nützliche Kontrollen, doch sie müssen bewusst entworfen und gepflegt werden.

Trennung kann die Architektur einer Organisation verbessern, wenn sie zu etablierten Fähigkeiten passt. Sie kann aber auch Latenz, mehr Koordination im Änderungsmanagement und eine größere Fehlerfläche hinzufügen. Bewerten Sie den gesamten Pfad vom Anwendungsprozess zur Datenbank, nicht nur den Datenbankhost.

• Kann die Anwendung den Datenbankendpunkt unter den erwarteten Fehlerbedingungen auflösen und erreichen?
• Welche Netzwerkpfade und Firewallregeln erlauben die Verbindung?
• Welche Datenbankrolle verwendet die Anwendung, und welche Berechtigungen benötigt sie tatsächlich?
• Wie werden Zugangsdaten bereitgestellt, rotiert und widerrufen?
• Wer genehmigt Wartungsarbeiten, die Anwendungsanbindung oder Schemakompatibilität beeinträchtigen könnten?
• Was geschieht, wenn die Datenbank erreichbar, aber nicht bereit, überlastet oder gerade in Wiederherstellung ist?

Gestalten Sie die Wiederherstellung als Verfahren für das Gesamtsystem

Ein Backup ist nur nützlich, wenn es den Dienst zu einem vereinbarten Wiederherstellungspunkt zurückbringen kann. Planen Sie die Wiederherstellung über den gesamten Datenpfad hinweg: die Datenbank, hochgeladene Dateien oder Objektspeicher, Anwendungskonfiguration, Secrets oder Verschlüsselungsmaterial sowie die richtige Wiederherstellungsreihenfolge. Eine erfolgreiche Wiederherstellung nur der Datenbank kann dennoch dazu führen, dass eine Anwendung Dateien nicht findet, sich nicht bei Diensten authentifizieren oder geschützte Daten nicht entschlüsseln kann.

Für PostgreSQL erfordert die Backup-Planung eine bewusste Wahl zwischen logischen Dumps, Backups auf Dateisystemebene und kontinuierlicher Archivierung. PostgreSQL dokumentiert diese als unterschiedliche Ansätze mit verschiedenen Stärken und Schwächen. Ein mit pg_dump erzeugter logischer Dump erstellt Befehle, die den Datenbankzustand wiederherstellen, der beim Beginn des Dumps erfasst wurde; er ist nicht gleichbedeutend mit dem bloßen Kopieren eines Container-Volumes.

Die Wiederherstellungsziele sollten die technische Wahl bestimmen. Wenn der erforderliche Wiederherstellungspunkt eine Wiederherstellung zu einem Zeitpunkt zwischen geplanten Backups verlangt, sind Funktionen erforderlich, die über gewöhnliche logische Dumps hinausgehen. Die Point-in-Time-Recovery von PostgreSQL basiert auf einem Basis-Backup plus kontinuierlicher Archivierung des Write-Ahead-Logs; die Ausgabe von logical pg_dump und pg_dumpall kann nicht für die Write-Ahead-Log-Wiedergabe verwendet werden.

Testen Sie Wiederherstellungen in einer isolierten Umgebung. Dokumentieren Sie Wiederherstellungsdauer, wiederhergestellten Zeitpunkt, durchgeführte Validierungsprüfungen, ungelöste manuelle Schritte und die Person, die das Ergebnis freigegeben hat. Bewerten Sie Nachweise aus einem Wiederherstellungstest höher als die Annahme, dass ein erfolgreich gemeldeter Backup-Job ausreicht.

• Ermitteln Sie für jede persistente Komponente die maßgebliche Quelle und die Backup-Methode.
• Legen Sie Ziele für Wiederherstellungspunkt und Wiederherstellungszeit fest, die das Team erklären und testen kann.
• Dokumentieren Sie die Wiederherstellungsreihenfolge, einschließlich Datenbanken, Dateien, Konfiguration und Secrets.
• Prüfen Sie die Identitäten, Rollen und Berechtigungen, die für die Wiederherstellung von Datenbankeigentum und Rechten erforderlich sind.
• Führen Sie regelmäßig Wiederherstellungstests durch und bewahren Sie deren Ergebnisse auf.
• Prüfen Sie nach der Wiederherstellung, dass die Validierung auf Anwendungsebene erfolgreich ist, nicht nur, dass der Datenbankdienst startet.

Weisen Sie Verantwortlichkeiten vor dem Produktionsstart zu

Die Architektur ist unvollständig, bis betriebliche Verantwortlichkeiten zugewiesen sind. Das gilt gleichermaßen für integrierte und externe Datenbanken. Eine Datenbank kann technisch erreichbar sein und dennoch betrieblich unsicher sein, weil niemand für privilegierten Zugriff, Speicherwachstum, Migrationsfehler oder die Verifizierung von Wiederherstellungen verantwortlich ist.

Machen Sie Verantwortlichkeiten in einem schlanken Runbook oder einer Service-Ownership-Dokumentation ausdrücklich. Es geht nicht um Bürokratie. Es soll sicherstellen, dass für eine fehlgeschlagene Migration, abgelaufene Zugangsdaten, ein wachsendes Volume oder eine Wiederherstellungsanfrage ein bekannter Reaktionsweg besteht.

Datenbankupgrades verdienen besondere Aufmerksamkeit. PostgreSQL dokumentiert explizite Upgradeverfahren für Hauptversionen, einschließlich Ansätzen mit Dump und Wiederherstellung. Ein Backup auf Dateisystemebene ist kein Ersatz für dieses dokumentierte Upgradeverfahren mit Dump und Wiederherstellung. Stimmen Sie die von der Anwendung unterstützten Datenbankversionen vor einem Wartungsfenster mit dem Datenbank-Upgradeverfahren ab.

• Wer führt Datenbank- und Anwendungsupdates durch?
• Wer kontrolliert Administratorzugriff und die üblichen Datenbankrollen der Anwendung?
• Wer rotiert Zugangsdaten und aktualisiert die Anwendungskonfiguration sicher?
• Wer überwacht Kapazität, Verbindungsfehler und Speicherwachstum?
• Wer genehmigt und führt Schemamigrationen durch?
• Wer reagiert, wenn eine Migration fehlschlägt oder ein Rollback erfordert?
• Wer verantwortet Backups, Wiederherstellungstests und die Freigabe von Wiederherstellungen?
• Wer koordiniert Upgrades auf Datenbank-Hauptversionen mit der Anwendungskompatibilität?