STACKIT · PostgreSQL und MongoDB
Datenbanken auf STACKIT migrieren und betreiben
Bevor Daten umziehen, steht fest, ob PostgreSQL Flex Ihre Anwendung trägt. Wir prüfen Rollen, Extensions, Backup-Takt und Wiederherstellung, wählen den Migrationspfad und verantworten Cutover und Abnahme.
- Migration relationaler und dokumentenorientierter Datenbanken
- Betrieb auf Wunsch
01Ausgangslage
Zuerst die Zielentscheidung, dann der Umzug
SKAFFON plant und führt die Migration relationaler und dokumentenorientierter Datenbanken nach STACKIT durch und betreibt sie auf Wunsch. Im Mittelpunkt steht PostgreSQL: Wir klären, ob STACKIT PostgreSQL Flex für Ihre Anforderungen reicht oder ob ein selbst betriebenes PostgreSQL besser passt.
Die Seite richtet sich an IT-Leitung und Datenbankverantwortliche. Allgemeine Methodik zur Datenübernahme steht unter Datenbankmigration, der Dauerbetrieb unter Managed PostgreSQL.
02Dokumentierte Grenzen
Fünf Stellen, an denen PostgreSQL Flex Ihre Planung begrenzt
Für die Planung sind die Grenzen wichtiger als die Funktionsliste. Das steht in der Dokumentation.
-
Backup einmal täglich
Backups laufen einmal täglich zu einer festgelegten UTC-Zeit; häufigere sind laut Dokumentation derzeit nicht möglich. Transaktionslogs sind standardmäßig aktiv, Point-in-Time-Wiederherstellung ist für alle Backups möglich. Abgelaufene Backups lassen sich nicht mehr wiederherstellen (Backup und Clone).
-
Restore nur als Clone
STACKIT bietet derzeit keine Wiederherstellung in die bestehende Instanz. Wiederherstellen heißt: Clone auf eine neue Instanz im selben Projekt zum gewählten Zeitpunkt und Clients umstellen. Das gehört in jedes Runbook.
-
Rollen ohne Superuser
Dokumentiert sind die Rollen login, createdb und createrole. Ein Superuser wird auf der Benutzerseite nicht erwähnt. Was das für Anwendungen bedeutet, die Superuser-Rechte annehmen, prüfen wir im Assessment.
-
Feste Extension-Liste
Es gilt eine Liste unterstützter Extensions, darunter pgvector, PostGIS, pg_partman, pg_repack und pgcrypto. Was Ihre Anwendung benötigt, wird dagegen geprüft.
-
PostgreSQL 15 läuft aus
PostgreSQL 15 wird abgekündigt; Support-Ende ist laut Dokumentation der 9. November 2027, bestehende Instanzen müssen auf Version 16 oder höher.
03
Ein Restore bei Flex ist immer ein Clone
Wer Flex betreibt, braucht ein Runbook, das mit einer neuen Instanz endet und nicht mit einem Zurückspielen.
04Verwalteter Dienst
Was STACKIT abnimmt und was im Vertrag stehen muss
Laut STACKIT ist PostgreSQL Flex ein vollständig verwalteter Dienst mit Wartung, Patching und Updates und „vollständig kompatibel zur nativen PostgreSQL-Datenbank“. Ein Replica-Set besteht aus drei Knoten, die einander vollständig spiegeln; eine Single-Instanz hat einen Knoten (Architektur, Instanzen anlegen, Produktseite).
Die Verfügbarkeit regelt die Servicebeschreibung STACKIT Cloud: 99,9 % im Kalendermonat, 99,5 % für nicht redundant ausgelegte Dienste, jeweils nach Abzug ausgeschlossener Ereignisse wie Wartungsarbeiten und sofern der Leistungsschein nichts Abweichendes regelt. Der Leistungsschein PostgreSQL Flex empfiehlt für Produktion ausdrücklich Replica-Sets, weil eine Single-Instanz bei Wartungsarbeiten vorübergehend nicht verfügbar sein kann. Für Backups nennt er ein RPO von vier Stunden, ein RTO von vier Stunden für Speicher unter 500 GB und 30 Tage Aufbewahrung als Standard; die Wiederherstellung liegt bei Ihnen als Kunde (Stand: 13.11.2026).
Wie Ihre Anwendung auf einen Knotenwechsel im Replica-Set reagiert, testen wir in der Probemigration und halten das Ergebnis im Runbook fest.
05Entscheidungsmatrix
PostgreSQL Flex oder CloudNativePG auf SKE
Selbst betrieben heißt hier typischerweise: PostgreSQL mit dem Operator CloudNativePG auf einem SKE-Cluster (SKE-Betrieb). CloudNativePG ist ein Open-Source-Operator, der Primary/Standby-Cluster mit Streaming-Replikation, automatisiertem Failover und kontinuierlichen Backups in Objektspeicher inklusive Point-in-Time-Recovery verwaltet. Als alternatives Sicherungswerkzeug für PostgreSQL auf eigenen Servern kommt pgBackRest in Frage, mit vollen, differenziellen und inkrementellen Backups und WAL-Archivierung auch in S3-kompatiblen Objektspeichern.
| Kriterium | PostgreSQL Flex | Selbst betrieben (z. B. CloudNativePG auf SKE) |
|---|---|---|
| Betriebsaufwand | Wartung, Patching, Updates durch STACKIT | Operator, Updates, Backups und Tests bei Ihnen oder SKAFFON |
| Backup-Takt | einmal täglich plus Transaktionslogs | frei konfigurierbar |
| Wiederherstellung | nur als Clone auf neue Instanz | je Werkzeug auch auf neuen Cluster zu einem Zeitpunkt; Verfahren selbst testen |
| Superuser, freie Extensions | Rollen und Extension-Liste begrenzt | volle Kontrolle, volle Verantwortung |
| Kubernetes-Nähe | Anbindung an SKE dokumentiert | gleiche Plattform, GitOps-fähig |
| Verantwortung bei Störung | geteilt, STACKIT-Vertrag maßgeblich | vollständig im Betriebsvertrag zwischen Ihnen und SKAFFON |
| Passt, wenn | Standard-Anwendung, Extensions auf der Liste, Betrieb möglichst delegiert | spezielle Extensions oder Rechte, feinere Backup-Ziele, einheitlicher Betrieb mit anderen Plattformen |
Die Wahl ist nicht endgültig: Beide Varianten sind PostgreSQL, ein späterer Wechsel läuft über dieselben Migrationspfade.
06Dokumentenorientiert
MongoDB bekommt einen eigenen Dienst
MongoDB nutzen Sie auf STACKIT als MongoDB Flex, einen verwalteten Dienst, der laut Dokumentation zu nativem MongoDB kompatibel ist und Verschlüsselung im Ruhezustand und bei der Übertragung sowie Auditing bietet.
Laut Architekturseite und Instanzen anlegen wählen Sie zwischen Single-Instanz (ein Knoten), Replica-Set aus drei Knoten, die einander vollständig spiegeln, und Sharded Cluster aus neun Knoten; das Sharding richten Sie über einen Sharding-Key selbst ein. Den Typ können Sie nach der Anlage nicht mehr ändern. Der Leistungsschein MongoDB Flex rät ausdrücklich davon ab, Single-Instanzen produktiv einzusetzen.
Gesichert werden Snapshots und Transaktionslogs; die Point-in-Time-Wiederherstellung reicht 30 Stunden zurück. Snapshots laufen alle 6, 8, 12 oder 24 Stunden, tägliche, wöchentliche und monatliche Snapshots haben eigene Aufbewahrungszeiten bis zu einem Jahr. Anders als bei PostgreSQL Flex spielen Sie ein Backup in dieselbe oder in eine andere Instanz im selben Projekt zurück (Backup, Restore und Clone). Der Leistungsschein nennt ein RPO von sechs Stunden, ein RTO von sechs Stunden für Speicher unter 1 TB und 14 Tage Aufbewahrung als Standard.
Bei der Anlage nennt die Anleitung die Versionen 7.0 und 8.0, Standard ist 8.0. Die Lifecycle-Seite führt für Version 7 ein Supportende im August 2026 und als Release-Policy eine Hauptversion pro Jahr, die mindestens 180 Tage nach Erscheinen der nächsten unterstützt wird. Die Zielversion legen wir in der Zielentscheidung fest. Updates plant und führt STACKIT laut Leistungsschein automatisiert aus; disruptive Wartungsarbeiten kündigt STACKIT laut Servicebeschreibung in der Regel zwei Wochen vorher auf der Status-Website an (Stand: 13.11.2026).
Für MongoDB Flex gilt derselbe Ablauf wie für PostgreSQL: Assessment, Zielentscheidung mit Instanztyp und Backup-Einstellungen nach Ihren Wiederherstellungszielen, Probemigration, Cutover mit Rückweg und Validierung mit Restore-Test. Den Betrieb übernehmen wir auf Wunsch.
07
Welcher Migrationspfad zu Ihrer Downtime-Toleranz passt
Welcher Pfad passt, bestimmen Datenvolumen, Änderungsrate und die Zeit, die das System offline sein darf. Das methodische Raster (Dump oder CDC) steht auf der Seite Datenbankmigration; die Tabelle ordnet es den STACKIT-Zielen zu.
| Ausgangslage | Pfad | Voraussetzung | Downtime |
|---|---|---|---|
| Kleine bis mittlere Datenbank, Wartungsfenster akzeptabel | Dump und Restore (pg_dump/pg_restore) | Extensions und Versionen am Ziel vorhanden | Dauer von Dump, Transfer und Restore |
| Große Datenbank, kurze Downtime | logische Replikation: initiale Kopie, danach laufende Änderungen, dann Umschalten | Quelle mit wal_level=logical; Rechte am Ziel | kurz, nur Cutover |
| Cloud-Datenbank mit Hersteller-Spezifika (z. B. Erweiterungen, Rollen) | Assessment der Abweichungen, dann einer der obigen Pfade | Liste der genutzten Extensions und Rollen | je nach Pfad |
| Ziel ist selbst betriebenes PostgreSQL | Basis-Backup und WAL-Wiederherstellung oder logische Replikation | Zugriff auf Quelle | je nach Pfad |
08Kurze Downtime
Logische Replikation: was sie leistet und was wir bei Flex vorab prüfen
Logische Replikation überträgt laut PostgreSQL-Dokumentation zuerst einen Snapshot der Tabellen und danach fortlaufend die Änderungen; sie ist ausdrücklich für den Wechsel zwischen Hauptversionen und Plattformen geeignet.
Am Ziel braucht sie das Recht, eine Subscription anzulegen: ab PostgreSQL 16 die Rolle pg_create_subscription und das CREATE-Recht auf der Datenbank (CREATE SUBSCRIPTION), unter PostgreSQL 15 Superuser-Rechte (Sicherheit, Version 15). Welche Rollen eine Flex-Instanz vergibt, hängt laut PostgreSQL-Flex-API v3 von der PostgreSQL-Version ab und lässt sich je Instanz abfragen. Ob ein Flex-Benutzer damit Subscriptions anlegen kann, prüfen wir in der Testmigration, bevor wir einen CDC-Pfad zusagen; bis dahin planen wir pro Projekt mit dem Pfad, den wir nachweisen können.
09Projektablauf
Von der Bestandsaufnahme bis zum Restore-Test
- 01
Assessment
Inventar der Datenbanken, Versionen, Extensions, Rollen, Größen, Änderungsraten und Abhängigkeiten der Anwendungen.
- 02
Zielentscheidung
Nach der Matrix oben, mit schriftlich festgehaltenen Annahmen.
- 03
Zielumgebung als Code
Instanzen, Benutzer und Netzwerkzugang mit dem Terraform Provider; Netzwerk nach der Landing Zone.
- 04
Probemigration
Mit Produktionskopie: Dauer, Abweichungen, Anwendungstest.
- 05
Cutover mit Rückweg
Die Quelle bleibt bis zur Abnahme unverändert erhalten.
- 06
Validierung
Zeilenzahlen und Prüfsummen, Anwendungstests, Restore-Test am Ziel nach dem dokumentierten Clone-Verfahren.
- 07
Übergabe oder Betrieb
Nach Managed PostgreSQL.
Abgenommen ist erst, was sich wiederherstellen lässt
Die Quelle bleibt bis zu Ihrer Abnahme unverändert, und die Validierung endet erst mit einem erfolgreichen Restore-Test am Ziel.
10Vorbereitung
Vier Dinge, ohne die kein Datenbank-Assessment startet
Die Zugangsdaten bleiben bei Ihnen.
- Zugriff auf Quelle und Dokumentation
- Liste der Anwendungen mit Ansprechpartnern und Wartungsfenstern
- Anforderungen an Wiederherstellung: wie viel Datenverlust, wie lange Ausfall
- Ihr STACKIT-Projekt
11Abgrenzung
Datenbankumzug: wo unsere Verantwortung liegt und wo nicht
Hier tragen wir Verantwortung
- Zielentscheidung, Migrationspfad, Cutover und Abnahme
- Betrieb nach der Migration auf Wunsch
Hier nicht
- Reiner Herstellersupport für PostgreSQL Flex: Den leistet STACKIT im Rahmen Ihres Vertrags.
- Datenbanken, die an Funktionen eines Hyperscaler-Datenbankdienstes hängen, die es als PostgreSQL oder MongoDB nicht gibt: Dann ist ein Anwendungsumbau Teil des Vorhabens, siehe Anwendungsmodernisierung.
- Die Erwartung einer Garantie von Downtime null ohne Probemigration.
12
Häufige Fragen
Kann ich PostgreSQL Flex in die bestehende Instanz zurückspielen?
Nach der Dokumentation derzeit nicht; die Wiederherstellung erfolgt als Clone auf eine neue Instanz.
Wie oft wird gesichert?
Backups laufen einmal täglich; Point-in-Time-Wiederherstellung ist über die Transaktionslogs möglich.
Was kostet die Migration?
Den Aufwand bestimmen Zahl und Größe der Datenbanken, Änderungsrate, zulässige Downtime, Abweichungen zwischen Quelle und Ziel sowie der Umfang von Test und Betrieb.