Es begann, wie so oft, mit einer scheinbar trivialen Entscheidung. Vor Jahren, bei der ersten Nextcloud-Installation, wurde einfach die Datenbank genommen, die gerade zur Hand war: MariaDB auf dem gleichen Server. Eine pragmatische Wahl. Doch mit der Zeit wuchs die Instanz, die Nutzerzahlen stiegen, und plötzlich war die Datenbank kein bloßer Begleiter mehr, sondern der zentrale Engpass. Die Logs zeigten langsame Abfragen, das UI reagierte träge, und die Backup-Fenster wurden unerträglich lang. Der Gedanke an eine Migration kam auf – weg von MariaDB hin zu PostgreSQL, das für seine Stabilität und fortgeschrittenen Features bei komplexen Abfragen bekannt ist. Was wie ein planbarer Wochenendjob aussah, entpuppte sich schnell als eine Operation mit vielen unbekannten Variablen.

Dabei zeigt sich: Die Datenbankmigration bei Nextcloud ist eine der grundlegendsten und gleichzeitig heikelsten Aufgaben für Administratoren. Sie berührt das Herzstück der Installation. Es geht nicht nur um das bloße Verschieben von Daten, sondern um einen fundamentalen Wechsel in der Architektur der Anwendung. Dieser Artikel beleuchtet die Gründe für einen solchen Schritt, die detaillierte Planung, die technische Durchführung und die Fallstricke, die auf dem Weg lauern. Denn eine gelungene Migration kann Nextcloud neuen Schwung verleihen. Eine gescheiterte kann zu Datenverlust und langen Ausfallzeiten führen.

Das Fundament: Warum die Datenbankwahl bei Nextcloud so entscheidend ist

Nextcloud abstrahiert die Datenbankschicht zwar weitgehend über Doctrine, einen Object-Relational Mapper (ORM). Für den Administrator bedeutet das im Alltag: Man muss sich nicht mit datenbankspezifischem SQL befassen, um die Anwendung zu betreiben. Doch diese Abstraktion hat Grenzen. Darunter arbeitet eine konkrete Datenbank-Engine mit ganz eigenen Charakteristika, Optimierungsmöglichkeiten und Limitierungen.

Nextcloud unterstützt offiziell MySQL/MariaDB, PostgreSQL und – mit Einschränkungen – Oracle. SQLite ist nur für Test- und Minimallösungen gedacht. Jede dieser Engines hat ihr eigenes Profil. MariaDB, der De-facto-Standard vieler Linux-Distributionen, ist schnell eingerichtet und für einfache Lese/Schreib-Operationen sehr performant. PostgreSQL hingegen gilt als der „strenge, aber gerechte“ Vertreter: ACID-konform bis in die letzte Konsequenz, mit einem mächtigen Query-Planner und exzellenter Unterstützung für komplexe Transaktionen und JSON-Daten. Das macht es besonders attraktiv für größere, komplexere Nextcloud-Instanzen, bei denen Datenintegrität und fortgeschrittene Abfragen im Vordergrund stehen.

Ein interessanter Aspekt ist die unterschiedliche Philosophie bei der Indizierung und Speicherung. Während MySQL/MariaDB oft als „einfacher“ wahrgenommen wird, erlaubt PostgreSQL eine feinere Kontrolle. Diese Unterschiede können bei einer Migration unerwartete Performance-Effekte nach sich ziehen. Eine Tabelle, die unter MariaDB flott lief, kann unter PostgreSQL erst nach einer Analyse der Abfragepläne und einer gezielten Index-Optimierung ähnlich schnell werden – oder sie läuft von Haus aus besser.

Der Auslöser: Wann eine Migration unumgänglich wird

Niemand migriert seine Datenbank aus einer Laune heraus. Hinter der Entscheidung stehen meist handfeste technische oder strategische Gründe.

Performance-Probleme sind der häufigste Treiber. Wenn die Nextcloud-Instanz wächst, steigen auch die Anforderungen an die Datenbank. Die oc_filecache-Tabelle, das Metadaten-Herzstück, kann bei vielen Dateien und vielen Nutzern enorm anschwellen. Ungünstige Indizes oder ein Query-Planner, der an seine Grenzen stößt, können hier zum Flaschenhals werden. Ein Wechsel zu PostgreSQL kann, richtig vorbereitet, eine deutliche Entlastung bringen – insbesondere bei komplexen JOIN-Operationen, die in der Aktivitäts- oder Freigabe-Ansicht anfallen.

Skalierungsstrategien sind ein weiterer Punkt. Vielleicht soll die Nextcloud-Instanz in eine Kubernetes-Umgebung integriert werden, wo hochverfügbare PostgreSQL-Cluster (etwa mit Patroni oder Cloud-native Angeboten) besser unterstützt werden als klassische MariaDB-Galera-Cluster. Oder die IT-Abteilung standardisiert auf eine bestimmte Datenbankplattform, um den Wartungsaufwand zu reduzieren.

Funktionale Anforderungen spielen ebenfalls eine Rolle. Bestimmte Nextcloud-App-Erweiterungen, besonders im Enterprise-Umfeld, können von PostgreSQL-spezifischen Features profitieren oder setzen diese sogar voraus. Auch der Wunsch nach einer stärkeren Integration mit anderen Systemen, die bereits auf PostgreSQL laufen, kann ein Argument sein.

Nicht zuletzt kann auch schlichtweg das Ende des Lebenszyklus einer alten Datenbankversion den Anstoß geben. Statt ein In-Place-Upgrade durchzuführen, nutzt man die Gelegenheit für einen grundlegenden Wechsel der Engine.

Die Vorbereitung: Planung ist die halbe Miete – und mehr

Der eigentliche Migrationsbefehl ist nur der letzte Schritt einer langen Kette von Vorbereitungen. Eine gründliche Planung ist der mit Abstand wichtigste Teil des gesamten Vorhabens.

Zunächst gilt es, einen vollständigen und konsistenten Backup zu erstellen. Das klingt banal, wird aber oft stiefmütterlich behandelt. Nicht nur die Datenbank muss gesichert werden, sondern auch das gesamte data/-Verzeichnis von Nextcloud. Wichtig: Die Instanz sollte während dieser Sicherung im Wartungsmodus laufen, um ein konsistentes Abbild zu gewährleisten. Ein Backup ohne Wartungsmodus ist im Ernstfall wertlos.

Als nächstes steht die Bestandsaufnahme an. Wie groß ist die aktuelle Datenbank wirklich? Welche Apps sind installiert, und welche Tabellen gehören dazu? Das Nextcloud-Occ-Tool (occ db:info) liefert hier erste Hinweise. Kritisch ist die Prüfung auf datenbankspezifische Abhängigkeiten. Nutzen interne Workflows oder bestimmte Apps möglicherweise MySQL-spezifische Syntax (z.B. LOCK IN SHARE MODE), die unter PostgreSQL nicht funktioniert? Hier hilft nur ein Studium der Dokumentation der jeweiligen Apps und im Zweifel ein Test in einer isolierten Umgebung.

Die Testumgebung ist der Schauplatz der Generalprobe. Sie muss so nah wie möglich am Produktivsystem sein – inklusive einer Kopie der Daten. Hier wird die Migration erstmals durchgespielt. Dieser Schritt dient nicht nur dazu, den Prozess zu validieren, sondern auch, um konkrete Performancedaten nach dem Wechsel zu sammeln. Laufen alle Cron-Jobs? Funktionieren die Datei-Scans? Sind die Antwortzeiten der Web-Oberfläche akzeptabel? Alle diese Fragen müssen in der Testumgebung beantwortet werden, bevor auch nur daran zu denken ist, die Produktion anzurühren.

Ein oft unterschätztes Element ist das Rollback-Szenario. Was tun, wenn während oder direkt nach der Migration etwas schiefgeht? Der Plan muss klar definieren, unter welchen Bedingungen abgebrochen und wie auf das alte System zurückgesetzt wird. Dazu gehört auch ein zeitliches Fenster: Wie lange darf der Ausfall maximal sein? Diese Information bestimmt maßgeblich die Wahl der Migrationsmethode.

Die Wahl der Migrationsmethode

Grundsätzlich stehen zwei Wege offen: Der Export/Import über SQL-Dumps und die logische Replikation.

Die Dump-Methode ist der klassische Weg. Mit Tools wie mysqldump oder pg_dump wird die Quell-Datenbank exportiert, das Ergebnis wird mit Konvertierungstools (wie pgloader oder selbstgeschriebenen Skripten) in das Format der Zieldatenbank transformiert und dann importiert. Vorteil: Einfach zu verstehen, gut dokumentiert. Nachteil: Sie benötigt ein signifikantes Downtime-Fenster, da die Nextcloud-Instanz für die gesamte Dauer des Exports, der Konvertierung und des Imports offline sein muss. Bei großen Datenbanken können das viele Stunden sein.

Die logische Replikation ist die elegantere, aber auch anspruchsvollere Methode. Dabei wird die Quell-Datenbank kontinuierlich in die Zieldatenbank gespiegelt, bis diese synchron ist. Zum Zeitpunkt des Wechsels muss Nextcloud dann nur kurz in den Wartungsmodus, um die finalen Differenzen anzugleichen und den Konnektor umzukonfigurieren. Die Downtime wird so auf Minuten reduziert. Tools wie pgloader im „online“-Modus oder binäre Log-basierte Replikationslösungen können hier zum Einsatz kommen. Die Einrichtung ist jedoch komplexer und setzt tiefere Kenntnisse beider Datenbanksysteme voraus.

Der Akt: Durchführung der Migration Schritt für Schritt

Gehen wir von der praxistauglicheren Dump-Methode für eine Migration von MariaDB zu PostgreSQL aus. In der gut vorbereiteten Testumgebung sieht der Ablauf nun wie folgt aus:

1. Wartungsmodus aktivieren: occ maintenance:mode --on. Dies stoppt alle Schreibvorgänge und stellt sicher, dass die Datenbank in einem konsistenten Zustand ist.
2. Finales Backup der Produktivdaten (in der Testumgebung: Kopie der Kopie): Nochmals Sicherheit schaffen.
3. Export der MariaDB-Datenbank: mysqldump --single-transaction --routines --events [Datenbankname] > nextcloud_dump.sql. Das Flag --single-transaction ist entscheidend für Konsistenz ohne globale Locks.
4. Vorbereitung der PostgreSQL-Zieldatenbank: Ein leeres Schema anlegen und den Nextcloud-Benutzer mit entsprechenden Rechten ausstatten.
5. Konvertierung und Import: Das ist der kniffligste Teil. Rohes MySQL-SQL läuft nicht unter PostgreSQL. Ein Tool wie pgloader übernimmt die schwere Arbeit. Eine einfache Konfigurationsdatei (my_migration.load) steuert den Vorgang:

   LOAD DATABASE
        FROM mysql://user:password@source_host/source_db
        INTO postgresql://user:password@target_host/target_db
    WITH include drop, create tables, create indexes, reset sequences, foreign keys
     SET maintenance_work_mem to '128MB', work_mem to '12MB';

   Der Befehl pgloader my_migration.load startet dann die Transformation. pgloader handelt Daten- und Schematypen intelligent um (z.B. TINYINT(1) zu BOOLEAN) und überträgt auch Indizes und Constraints.

6. Prüfung des Imports: Stimmen die Zeilenanzahlen der wichtigsten Tabellen (oc_users, oc_filecache)? Gibt es Fehler in den Logs von pgloader?
7. Anpassung der Nextcloud-Konfiguration: In der config/config.php muss der Datenbanktreiber umgestellt werden. Die Zeile 'dbtype' => 'mysql', wird zu 'dbtype' => 'pgsql',. Zugangsdaten und Datenbankname müssen angepasst werden.
8. Datenbank-Update durch Nextcloud: Nach dem Wechsel führt man occ maintenance:data-fingerprint und occ db:convert-filecache-bigint (falls nötig) aus. Vor allem aber muss Nextcloud selbst die Datenbank noch einmal „anschauen“: occ maintenance:repair kann Probleme aufdecken. Im Idealfall erkennt Nextcloud das neue Schema und kommt damit sofort zurecht.
9. Wartungsmodus deaktivieren und Funktionsprüfung: occ maintenance:mode --off. Nun folgt ein intensives manuelles und automatisiertes Testen aller Kernfunktionen: Login, Dateizugriff, Freigaben, Versionierung, Aktivitätsstream, App-spezifische Features.

Erst wenn dieser komplette Ablauf in der Testumgebung mehrfach reibungslos und mit den gewünschten Performance-Charakteristika durchgelaufen ist, darf an die Produktion gedacht werden.

Die Fallstricke: Wo es haken kann

Trotz bester Vorbereitung lauern einige typische Probleme. Einer der häufigsten Fehler sind Zeichensatz-Probleme. Wenn die Quell-Datenbank mit latin1 lief, die Zieldatenbank aber auf UTF8 besteht, können Umlaute und Sonderzeichen zu Kauderwelsch werden. Die Konvertierung muss bereits beim Export oder spätestens im Import-Tool korrekt spezifiziert werden.

Unterschiedliche Sortierungen (Collations) sind eine subtilere Fehlerquelle. Die Sortierung von Zeichenketten kann zwischen MySQL und PostgreSQL variieren. Das mag bei der Suche in der Nextcloud-Weboberfläche kaum auffallen, könnte aber interne Logik von Apps beeinflussen, die alphabetische Sortierung voraussetzen.

Die Behandlung von NULL und leeren Strings ist in den Datenbanken historisch bedingt unterschiedlich. Wo MySQL zwischen einer leeren Zeichenkette ("") und NULL unterscheidet, behandelt PostgreSQL sie in bestimmten Kontexten strenger. Das Nextcloud-Schema ist dafür zwar ausgelegt, aber selbstgeschriebene Erweiterungen könnten hier Schwierigkeiten bekommen.

Ein technischer, aber wichtiger Punkt: Sequenzen (für Auto-Increment IDs). Nach dem Import müssen die Sequenzen in PostgreSQL auf den korrekten Maximalwert der jeweiligen Spalte gesetzt werden, sonst gibt es beim nächsten Einfügen einen Primärschlüssel-Konflikt. pgloader übernimmt das normalerweise automatisch mit der Option reset sequences, aber es schadet nicht, dies manuell zu überprüfen.

Der vielleicht größte Stolperstein sind jedoch Third-Party-Apps. Eine App, die direkt auf Datenbankebene mit eigenen Tabellen arbeitet und MySQL-spezifische SQL-Konstrukte verwendet, wird unter PostgreSQL nicht funktionieren. Hier bleibt nur: Vor der Migration prüfen, ob es eine PostgreSQL-kompatible Version gibt, oder die App deaktivieren und nach Alternativen suchen.

Die Nachbereitung: Optimierung und Feintuning

Ist die Migration geschafft und Nextcloud läuft stabil, beginnt die eigentliche Arbeit erst: das Optimieren der neuen Plattform. PostgreSQL bietet ein mächtiges Arsenal an Analysewerkzeugen.

Das PostgreSQL-Tool pg_stat_statements sollte umgehend aktiviert werden. Es zeichnet alle ausgeführten Abfragen auf und liefert Daten zu deren Laufzeit und Häufigkeit. So identifiziert man schnell die neuen Performance-Kandidaten in der Nextcloud-Instanz.

Die VACUUM- und ANALYZE-Strategie muss konfiguriert werden. Während MySQL/MariaDB dies eher im Hintergrund handhaben, erlaubt PostgreSQL hier eine präzise Steuerung. Gerade nach einem Massenimport ist ein manuelles VACUUM ANALYZE; sinnvoll, um die Statistiken für den Query-Planner auf den neuesten Stand zu bringen. Für produktive Systeme sollte die Autovacuum-Funktion sinnvoll konfiguriert werden, um eine Tabellenaufblähung (Bloat) zu verhindern.

Die Indizes verdienen besondere Aufmerksamkeit. Das von Nextcloud mitgelieferte Schema enthält eine Basis-Indizierung. Unter der neuen Engine kann es sein, dass andere Indizes vorteilhafter sind. Anhand der Slow Queries aus pg_stat_statements kann man gezielt neue Indizes hinzufügen. Dabei ist Vorsicht geboten: Jeder Index verlangsamt Schreibvorgänge. Eine Analyse mit EXPLAIN ANALYZE vor und nach der Index-Erstellung ist Pflicht.

Ein weiterer Hebel sind die PostgreSQL-Konfigurationsparameter in der postgresql.conf. Werte wie shared_buffers, work_mem oder maintenance_work_mem sind stark systemspezifisch und sollten an die verfügbare RAM-Ausstattung und die Lastmuster der Nextcloud-Instanz angepasst werden. Pauschale Empfehlungen sind hier schwierig; das Experimentieren in der Testumgebung zahlt sich aus.

Fazit: Eine Investition in die Zukunft

Eine Nextcloud-Datenbankmigration ist kein Projekt für einen ruhigen Nachmittag. Sie erfordert akribische Planung, eine zuverlässige Testumgebung und ein solides Verständnis sowohl der Quelle als auch des Ziels. Der Aufwand ist beträchtlich.

Doch die Mühe kann sich mehrfach lohnen. Eine erfolgreiche Migration zu einer leistungsfähigeren oder besser in die Infrastruktur integrierbaren Datenbank-Engine kann die Skalierbarkeit und Stabilität der gesamten Nextcloud-Instanz auf ein neues Level heben. Sie beseitigt nicht nur akute Performance-Probleme, sondern schafft auch die Grundlage für zukünftiges Wachstum.

Letztlich ist es eine architektonische Entscheidung mit langfristiger Wirkung. Wer sie sorgfältig angeht, behandelt die Nextcloud-Datenbank nicht länger als bloßen persistenten Speicher, sondern als eine zentrale, aktive Komponente seiner Kollaborationsplattform. Und das ist genau der richtige Ansatz für eine Infrastruktur, die heute mehr denn im Zentrum der digitalen Zusammenarbeit steht. In diesem Sinne ist eine gelungene Migration weniger ein notwendiges Übel, sondern vielmehr ein strategischer Weichensteller für die Zukunft der eigenen Digital-Infrastruktur.