--- title: "Datenbanken auf STACKIT: PostgreSQL Flex migrieren, betreiben" description: "PostgreSQL und MongoDB auf STACKIT: Migrationspfade, Grenzen von PostgreSQL Flex bei Backup und Rollen, und wann CloudNativePG auf SKE besser passt." url: https://skaffon.de/stackit/datenbanken/ --- ![Reihe von Laufwerksschächten mit grünen Statusleuchten in einem blau beleuchteten Speichersystem](/_astro/laufwerksschaechte-speichersystem-blau.CyT8wQjI_Z5sUKx.jpg) 1. [Startseite](/) 2. [STACKIT](/stackit/) 3. Datenbanken auf STACKIT migrieren und betreiben 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. [Projekt anfragen](/projekt-anfragen/) [Flex oder CloudNativePG](/stackit/datenbanken/#postgresql-flex-oder-cloudnativepg-auf-ske) - Migration relationaler und dokumentenorientierter Datenbanken - Betrieb auf Wunsch Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Ausgangslage ## 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](https://docs.stackit.cloud/products/databases/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](/daten/datenbank-migration/), der Dauerbetrieb unter [Managed PostgreSQL](/managed-services/managed-postgresql/). Quelle der Angaben Alle Produktangaben zu PostgreSQL Flex haben wir aus der STACKIT-Dokumentation gelesen (Stand: 13.11.2026). Dokumentierte 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](https://docs.stackit.cloud/products/databases/postgresql-flex/how-tos/backup-and-clone-postgresql-flex/)). - ### 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](https://docs.stackit.cloud/products/databases/postgresql-flex/how-tos/create-and-manage-users-for-postgresql-flex/) 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](https://docs.stackit.cloud/products/databases/postgresql-flex/reference/supported-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. ## 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. Verwalteter 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](https://docs.stackit.cloud/products/databases/postgresql-flex/basics/architecture-of-postgresql-flex/), [Instanzen anlegen](https://docs.stackit.cloud/products/databases/postgresql-flex/how-tos/create-and-manage-instances-for-postgresql-flex/), [Produktseite](https://stackit.com/en/products/database/stackit-postgresql-flex)). Die Verfügbarkeit regelt die [Servicebeschreibung STACKIT Cloud](https://stackit.com/de/asset/download/51710/file/STACKIT%2520Cloud%2520Servicebeschreibung%5FDE.pdf): 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](https://stackit.com/de/asset/download/34257/file/Leistungsschein%5FSTACKIT%5FPostgreSQL%5FFlex.pdf) 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. ![Gestapelte interne Festplatten mit sichtbarer türkisfarbener Platine auf weißem Untergrund](/_astro/festplatten-gestapelt-platinen.H791G0k-_Z2lMxAa.jpg) Entscheidungsmatrix ## PostgreSQL Flex oder CloudNativePG auf SKE Selbst betrieben heißt hier typischerweise: PostgreSQL mit dem Operator [CloudNativePG](https://cloudnative-pg.io/) auf einem SKE-Cluster ([SKE-Betrieb](/stackit/managed-kubernetes/)). 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](https://pgbackrest.org/) in Frage, mit vollen, differenziellen und inkrementellen Backups und WAL-Archivierung auch in S3-kompatiblen Objektspeichern. __Vergleich von PostgreSQL Flex und selbst betriebenem PostgreSQL nach Betrieb, Backup, Restore, Rechten und Verantwortung__ | 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. Dokumentenorientiert ## MongoDB bekommt einen eigenen Dienst MongoDB nutzen Sie auf STACKIT als [MongoDB Flex](https://docs.stackit.cloud/products/databases/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](https://docs.stackit.cloud/products/databases/mongodb-flex/basics/architecture/) und [Instanzen anlegen](https://docs.stackit.cloud/products/databases/mongodb-flex/how-tos/create-and-manage-instances/) 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](https://stackit.com/de/asset/download/34253/file/Leistungsschein%5FSTACKIT%5FMongoDB%5FFlex.pdf) 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](https://docs.stackit.cloud/products/databases/mongodb-flex/how-tos/backup-restore-and-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](https://docs.stackit.cloud/products/databases/mongodb-flex/reference/lifecycle/) 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](https://stackit.com/de/asset/download/51710/file/STACKIT%2520Cloud%2520Servicebeschreibung%5FDE.pdf) 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. ## 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](/daten/datenbank-migration/); die Tabelle ordnet es den STACKIT-Zielen zu. __Migrationspfade nach Ausgangslage mit Voraussetzung und erwarteter Downtime__ | 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 | Kurze Downtime ## Logische Replikation: was sie leistet und was wir bei Flex vorab prüfen Logische Replikation überträgt laut [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/logical-replication.html) 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](https://www.postgresql.org/docs/current/sql-createsubscription.html)), unter PostgreSQL 15 Superuser-Rechte ([Sicherheit, Version 15](https://www.postgresql.org/docs/15/logical-replication-security.html)). Welche Rollen eine Flex-Instanz vergibt, hängt laut [PostgreSQL-Flex-API v3](https://github.com/stackitcloud/stackit-api-specifications/blob/main/services/postgres-flex/v3/postgres-flex.json) 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. ![Nahaufnahme von Quellcode auf einem dunklen Bildschirm mit geringer Schärfentiefe](/_astro/quellcode-bildschirm-unscharf.CedyeZDL_vVmqb.jpg) Projektablauf ## Von der Bestandsaufnahme bis zum Restore-Test 1. 01 ### Assessment Inventar der Datenbanken, Versionen, Extensions, Rollen, Größen, Änderungsraten und Abhängigkeiten der Anwendungen. 2. 02 ### Zielentscheidung Nach der Matrix oben, mit schriftlich festgehaltenen Annahmen. 3. 03 ### Zielumgebung als Code Instanzen, Benutzer und Netzwerkzugang mit dem [Terraform Provider](https://registry.terraform.io/providers/stackitcloud/stackit/latest/docs); Netzwerk nach der [Landing Zone](/stackit/landing-zone/). 4. 04 ### Probemigration Mit Produktionskopie: Dauer, Abweichungen, Anwendungstest. 5. 05 ### Cutover mit Rückweg Die Quelle bleibt bis zur Abnahme unverändert erhalten. 6. 06 ### Validierung Zeilenzahlen und Prüfsummen, Anwendungstests, Restore-Test am Ziel nach dem dokumentierten Clone-Verfahren. 7. 07 ### Übergabe oder Betrieb Nach [Managed PostgreSQL](/managed-services/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. Vorbereitung ## 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 Abgrenzung ## 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](/software/application-modernisierung/). - Die Erwartung einer Garantie von Downtime null ohne Probemigration. ## 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. ## Welche Datenbanken ziehen um, und wie lange darf es dauern? Schildern Sie Ihre Datenbanken und die zulässige Downtime. Zurück zur Übersicht: [STACKIT](/stackit/); Fragen vorab über den [Kontakt](/kontakt/). [Projekt anfragen](/projekt-anfragen/) [Kontakt](/kontakt/)