2026 n8n von SQLite zu PostgreSQL migrieren: Wie bleiben Workflows erhalten?

Symptom: Nach dem Ändern der Datenbankkonfiguration startet n8n mit einer leeren PostgreSQL-Datenbank, während die bisherigen Workflows in der SQLite-Instanz liegen.

Schnellste sichere Lösung: Ändern Sie nicht nur die Verbindungswerte. Sichern Sie zuerst die bestehende Instanz, legen Sie den erforderlichen Datenumfang fest und migrieren Sie unterstützte Objekte nach dem offiziellen Weg Ihrer n8n-Version. Prüfen Sie anschließend Workflows, Zugangsdaten, Benutzerbeziehungen und Ausführungen einzeln.

Für unabhängige Entwickler: Wenn eine SQLite-Instanz dauerhaft produktive Workflows ausführt und unklar ist, welche Daten beim Umzug erhalten bleiben, führt dieser Leitfaden durch die Entscheidung.

Für kleine Teams: Wenn gemeinsame Workflows, Zugangsdaten oder Benutzer- und Projektbeziehungen wichtig sind, finden Sie hier die Prüfpunkte für Berechtigungen und Sichtbarkeit.

Für Upgrade-Verantwortliche: Wenn die Datenbankmigration mit einem Upgrade auf n8n 2.x verbunden werden soll, erfahren Sie, wie beide Änderungen getrennt geplant und abgenommen werden.

Zuletzt aktualisiert am 31.10.2026; Angaben anhand der offiziellen n8n-Dokumentation zu Datenbanken, CLI-Funktionen und Versionsänderungen geprüft. Die Dokumentation ist versionsabhängig und sollte vor einer produktiven Änderung erneut geprüft werden.

Die Migrationsentscheidung nach dem benötigten Datenumfang treffen

Die n8n-Dokumentation beschreibt SQLite als Standarddatenbank und PostgreSQL als unterstützte Datenbankoption. Daraus folgt jedoch kein automatischer Kopiervorgang: Eine neue Datenbankkonfiguration weist n8n auf ein anderes Datenbanksystem hin, überträgt aber nicht von selbst die vorhandenen Datensätze. Prüfen Sie daher zuerst die offizielle Übersicht zu unterstützten Datenbanken und Einstellungen.

Der passende Weg hängt davon ab, was nach dem Wechsel noch verfügbar sein muss:

• Für eine private Testinstanz kann es genügen, die bestehende SQLite-Datenbank und die zugehörigen Dateien verlässlich zu sichern. Wenn keine produktiven Abläufe daran hängen, lässt sich ein frischer PostgreSQL-Test getrennt aufbauen.
• Für den produktiven Einzelbetrieb sollten mindestens die benötigten Workflows und Zugangsdaten identifiziert und über die dokumentierten CLI-Funktionen verarbeitet werden. Prüfen Sie gesondert, welche weiteren Einstellungen und Dateien für die konkrete Bereitstellung relevant sind.
• Für ein Team sind zusätzlich Benutzer, Projekte, geteilte Workflows und deren Beziehungen zu untersuchen. Ein erfolgreicher Import einzelner Workflows beweist nicht, dass die bisherige Teamstruktur wiederhergestellt wurde.
• Bei vorgeschriebener Ausführungshistorie muss zuerst ein für die installierte Version belegter Migrationsweg gefunden und auf einer Kopie geprüft werden. Ist das nicht möglich, sollte die Migration nicht mit der Zusage einer vollständigen Historienübernahme geplant werden.

Die zentrale Abgrenzung lautet: SQLite, PostgreSQL, Workflow- und Zugangsdaten-Exporte sowie Dateispeicher sind nicht dasselbe Migrationsobjekt. Ein vollständiger Umzug kann deshalb mehrere Prüfungen und Sicherungen benötigen.

Entscheidungszweige für den geeigneten Weg

Nutzen Sie die folgenden Bedingungen, bevor Sie produktive Einstellungen ändern:

• Wenn keine alten Ausführungen und keine produktiven Daten benötigt werden, dann sichern Sie die bisherige Instanz und prüfen Sie zunächst eine frische PostgreSQL-Installation. Übernehmen Sie nur die Geschäftsobjekte, deren Import für Ihre Version dokumentiert und getestet ist.
• Wenn Workflows und Zugangsdaten gebraucht werden, die Historie aber entbehrlich ist, dann planen Sie einen gezielten Export und Import dieser Objekte. Kontrollieren Sie dabei Kennungen, Verschlüsselungsschlüssel und die Funktion der Zugangsdaten in der Zielinstanz.
• Wenn Benutzer, Projekte oder Freigaben für die Zusammenarbeit entscheidend sind, dann betrachten Sie einen reinen Workflow- und Zugangsdatenimport nicht als ausreichende Migration. Verifizieren Sie die Zuordnung auf einer Kopie und vergleichen Sie die tatsächliche Sichtbarkeit mit der vorherigen Instanz.
• Wenn die Ausführungshistorie erhalten bleiben muss, dann starten Sie erst mit der produktiven Migration, nachdem ein passender Weg anhand der offiziellen Dokumentation und eines Testlaufs geprüft wurde. Community-Skripte sind dabei keine Bestätigung offizieller Unterstützung.
• Wenn zugleich ein Upgrade auf n8n 2.x geplant ist, dann trennen Sie Datenbankmigration und Versionswechsel. Prüfen Sie den offiziellen Migrationsbericht für Version 2 und die Änderungen mit möglichen Auswirkungen auf bestehende Installationen, bevor Sie den Upgrade-Teil terminieren.

Datenarten vor dem Export einzeln erfassen

Eine belastbare n8n-Datenbankmigration beginnt mit einer Bestandsaufnahme. Notieren Sie nicht nur, wie viele Workflows vorhanden sind, sondern auch, welche Funktionen nach dem Umzug unverändert verfügbar sein müssen.

Workflows und Kennungen

Die offiziellen CLI-Funktionen unterstützen den Export und Import von Workflows. Die passenden Befehle und ihre Optionen sind in der n8n-CLI-Dokumentation beschrieben. Lesen Sie dort die Angaben für die konkret eingesetzte Version, bevor Sie Befehle in einer produktiven Umgebung verwenden.

Besonders wichtig sind die Workflow-IDs: Beim Import kann es je nach Optionen und Zielzustand zu Überschreibungen kommen. Exportieren Sie deshalb nicht ungeprüft in eine Instanz, die bereits andere oder gleichnamige Objekte enthält. Halten Sie fest, welche Workflows ersetzt werden dürfen und welche als eigenständige Einträge erhalten bleiben müssen.

Zugangsdaten und Verschlüsselungsschlüssel

Zugangsdaten sind nicht bloß Textfelder, die mit einem Workflow mitwandern. Prüfen Sie, ob der bisherige Verschlüsselungsschlüssel für die Zielinstanz verfügbar ist und ob der für Ihre Installation verwendete Schlüssel nach dem Umzug unverändert eingesetzt werden kann. Ohne passenden Schlüssel kann ein Import oder die spätere Nutzung von Zugangsdaten scheitern.

Behandeln Sie Schlüsselmaterial wie ein Geheimnis: Es gehört nicht in öffentlich zugängliche Protokolle, ein gemeinsames Ticket oder ein ungeschütztes Exportverzeichnis. Eine exportierte Datei sollte nur so lange und nur an einem abgesicherten Ort vorliegen, wie es für den geprüften Umzug erforderlich ist.

Benutzer, Projekte und Freigaben

Workflow-Importe sind nicht automatisch eine Wiederherstellung aller Benutzer- und Projektbeziehungen. Für Teaminstanzen muss sichtbar sein, wer einen Workflow besitzt, wer ihn bearbeiten darf und welche Zugangsdaten im jeweiligen Projekt verfügbar sind. Prüfen Sie die Dokumentation zum Teilen von Workflows und testen Sie die resultierenden Berechtigungen mit den tatsächlichen Rollen der Beteiligten.

Ausführungshistorie und Binärdaten

Ausführungsdaten sollten separat betrachtet werden: Sie dienen anderen Zwecken als Workflow-Definitionen und Zugangsdaten und können je nach Aufbewahrungseinstellungen unterschiedlich stark anwachsen. Lesen Sie die offiziellen Hinweise zu Aufbewahrung und Bereinigung von Ausführungsdaten, bevor Sie entscheiden, ob die Historie übernommen oder nach einem dokumentierten Verfahren begrenzt werden soll.

Prüfen Sie außerdem, ob die Workflows Dateien oder andere Binärdaten erzeugen. Die Datenbankmigration allein belegt nicht, dass externe oder dateibasierte Ablagen mitkopiert wurden. Die n8n-Dokumentation zur Speicherung von Binärdaten hilft, die für die eigene Bereitstellung relevante Speicherart zu identifizieren.

Die Migration mit einer überprüfbaren Rückfalloption vorbereiten

Vor dem ersten Eingriff sollten die bisherige Instanz und die Zielumgebung getrennt voneinander betrachtet werden. Die vorhandene SQLite-Datei ist keine vollständige Sicherung, wenn zusätzlich Binärdaten, Konfiguration oder der Schlüssel für verschlüsselte Zugangsdaten gebraucht werden. Erfassen Sie daher, welche Verzeichnisse, Umgebungswerte und externen Speicherorte zur konkreten Bereitstellung gehören.

1. Version und Bereitstellung dokumentieren. Halten Sie die installierte n8n-Version, das Container- oder Installationsverfahren, relevante Datenpfade und die aktuell verwendete Datenbankkonfiguration fest. Für einen Wechsel auf n8n 2.x ist der offizielle Migrationsbericht separat heranzuziehen.
2. Übernahmeumfang schriftlich festlegen. Markieren Sie Workflows, Zugangsdaten, Benutzer- und Projektbeziehungen, Ausführungshistorie sowie Binärdaten jeweils als erforderlich oder entbehrlich. Begründen Sie besonders, warum historische Ausführungen aufbewahrt werden müssen oder nicht.
3. Sicherung erstellen und Wiederherstellung prüfen. Sichern Sie die SQLite-Datenbank konsistent mit dem Betriebszustand, dazu alle für die Instanz benötigten Dateien und geheimen Konfigurationswerte. Eine Sicherung, deren Wiederherstellung nie getestet wurde, sollte nicht als nachgewiesener Rückweg gelten.
4. Zielinstanz isoliert aufsetzen. Konfigurieren Sie PostgreSQL nach den offiziellen Einstellungen für Ihre n8n-Version. Halten Sie Zielsystem und produktive Instanz zunächst getrennt, damit Tests nicht versehentlich reale Webhooks oder produktive Abläufe auslösen.
5. Unterstützte Objekte exportieren und importieren. Verwenden Sie die dokumentierten CLI-Funktionen für Workflows und Zugangsdaten. Lesen Sie vor dem Import die Hinweise zu Optionen und möglichen ID-Überschreibungen; bewahren Sie Exportdateien geschützt auf und entfernen Sie sie nach erfolgreicher Prüfung gemäß den eigenen Sicherheitsvorgaben.
6. Nicht abgedeckte Daten gesondert verifizieren. Testen Sie Benutzer, Projekte, Freigaben, Ausführungshistorie und Binärdaten jeweils entsprechend ihrer eigenen Bedeutung. Behandeln Sie ein nicht dokumentiertes Verfahren nicht als offiziell abgesicherten Teil des Umzugs.
7. Umschalten und Rückweg festlegen. Wechseln Sie erst, wenn die Abnahme abgeschlossen ist. Definieren Sie vorab, welche Fehler die Rückkehr zur gesicherten Instanz auslösen und wie verhindert wird, dass nach dem Umschalten neu erzeugte Daten stillschweigend verloren gehen.

Diese Reihenfolge ist kein Versprechen einer unterbrechungsfreien Migration. Dauer, notwendige Betriebsunterbrechung und konkrete Wiederherstellbarkeit hängen von der Bereitstellung und den geprüften Verfahren ab und sollten nicht ohne Testlauf zugesagt werden.

Die Abnahme an den Aufgaben der Beteiligten ausrichten

Ein technischer Startbildschirm reicht nicht als Abnahme. Prüfen Sie die Funktionen aus Sicht der Personen, die n8n tatsächlich warten und nutzen:

• Wartung: Anmeldung, Zugriff auf die erwarteten Projekte und Anzeige der vorgesehenen Workflows funktionieren.
• Workflow-Verantwortliche: Ein zuvor ausgewählter Workflow lässt sich öffnen, bearbeiten, aktivieren und kontrolliert ausführen.
• Verantwortliche für Zugangsdaten: Zugangsdaten sind vorhanden und werden bei einem erlaubten Testaufruf tatsächlich akzeptiert; kein Geheimnis darf zu diesem Zweck in Protokolle kopiert werden.
• Automatisierungsverantwortliche: Zeitgesteuerte Abläufe und Webhook-Auslöser funktionieren in der Zielumgebung. Prüfen Sie, dass Testläufe keine produktiven Drittsysteme unbeabsichtigt verändern.
• Teamverantwortliche: Sichtbarkeit, Bearbeitungsrechte, Workflow-Zuordnung und Zugriff auf gemeinsam benötigte Zugangsdaten entsprechen dem vorher festgelegten Soll.
• Betrieb: Ausführungseinträge und erforderliche Dateien sind entsprechend der gewählten Aufbewahrung und Speicherart verfügbar. Die Abnahme muss erkennen lassen, ob Historie vollständig, absichtlich eingeschränkt oder nicht übernommen wurde.

Führen Sie die Prüfung erst mit Testdaten durch. Danach kann ein kontrollierter produktiver Test erfolgen, dessen Ergebnis und beobachtete Unterschiede dokumentiert werden. Wenn eine Rolle oder ein Datenbereich nicht geprüft werden konnte, sollte die Migration nicht als vollständig abgenommen gelten.

Das Upgrade von der Datenbankmigration trennen

Ein Versionswechsel verändert möglicherweise mehr als die Datenbankverbindung. Wenn die Instanz zusätzlich auf n8n 2.x aktualisiert werden soll, planen Sie zuerst den Datenbankumzug mit der bestehenden Version und nehmen Sie ihn separat ab. Prüfen Sie danach die offiziellen Hinweise zu den 2.0-Änderungen und zum Migrationsbericht für das gewählte Ziel.

So bleibt die Fehlersuche eingegrenzt: Wenn ein Workflow nach der Datenbankmigration nicht mehr verfügbar ist, lässt sich zunächst prüfen, ob Import, Kennung oder Berechtigung die Ursache ist. Treten Probleme erst nach dem Upgrade auf, kann der Versionswechsel separat untersucht werden. Ein Community-Fall mit einer bestimmten Kombination aus Version und Datenbank ersetzt keine Prüfung für die eigene Installation.

Bewahren Sie die ursprüngliche Datenbankkopie und die zugehörige Konfiguration so lange auf, wie sie für den vorher festgelegten Rückweg benötigt werden. Ein Rollback ist nicht automatisch verlustfrei, wenn in der Zielinstanz bereits neue Ausführungen oder Änderungen entstanden sind. Legen Sie daher vor der Umschaltung fest, wie solche Änderungen behandelt werden.

Speicherbedarf und Betriebsumgebung mit realen Daten abgleichen

PostgreSQL macht eine Instanz nicht automatisch hochverfügbar und stellt keine automatische Sicherung bereit. Auch die Verteilung von Datenbank, n8n und Binärdateien auf dieselbe oder unterschiedliche Systeme ist eine Betriebsentscheidung, die Ausfallbereiche, Wartung und Wiederherstellung beeinflusst.

Schätzen Sie den Speicherbedarf anhand der vorhandenen Daten und der vorgesehenen Aufbewahrung: Wie viel Platz belegen Datenbank und Dateien aktuell? Welche Ausführungsdaten bleiben erhalten? Gibt es größere Binärdaten? Wie lange sollen Sicherungen aufbewahrt werden, und liegen sie getrennt vom Produktivsystem? Verwenden Sie dafür Messwerte aus der eigenen Instanz statt einer pauschalen Konfigurationsschwelle.

Häufige Fragen zur n8n-Migration

Reicht es aus, für PostgreSQL die Datenbankvariablen zu ändern?

Nein. Die Konfiguration legt fest, mit welcher Datenbank n8n arbeitet, aber sie kopiert die bisherigen SQLite-Datensätze nicht. Ohne vorherigen Export oder einen für die konkrete Version dokumentierten Migrationsweg kann die Zielinstanz deshalb ohne die erwarteten Workflows starten. Sichern Sie zuerst die Ausgangsinstanz und prüfen Sie den tatsächlichen Datenumfang.

Können Workflows und Zugangsdaten gemeinsam exportiert werden?

Die n8n-CLI bietet dokumentierte Funktionen für den Export und Import von Workflows und Zugangsdaten. Planen Sie die Verarbeitung dennoch als getrennte Prüfpunkte, denn Kennungen, Verschlüsselungsschlüssel und Zielzustand können unterschiedliche Fehler verursachen. Prüfen Sie die CLI-Optionen für die eingesetzte Version und verifizieren Sie danach die tatsächliche Nutzung der importierten Zugangsdaten.

Ist die Ausführungshistorie automatisch Teil des CLI-Imports?

Ein erfolgreicher Import von Workflow-Definitionen und Zugangsdaten belegt keine vollständige Übernahme der Historie. Historische Ausführungen sind gesondert zu bewerten; der geeignete Weg hängt von Version und Datenart ab. Wenn sie aus betrieblichen oder internen Gründen erhalten bleiben müssen, testen Sie die Übernahme und Wiederherstellung auf einer Kopie, bevor Sie die produktive Datenbank umstellen.

Sollte der Wechsel auf PostgreSQL gleichzeitig mit dem Upgrade auf n8n 2.x erfolgen?

Planen Sie beides möglichst als getrennte Änderungen. Prüfen Sie zuerst die Datenbankmigration und deren Abnahme mit der bestehenden Version. Danach kontrollieren Sie anhand des offiziellen Migrationsberichts und der Hinweise zu Änderungen, ob das Upgrade weitere Anpassungen erfordert. So können Sie Fehler besser zuordnen und die unveränderte Ausgangsdatenbank als Rückfalloption behalten.

Wer nach der Bestandsaufnahme feststellt, dass eine dauerhaft betriebene n8n-Instanz durch geteilte Ressourcen, begrenzten Speicherplatz oder unklare Speicherzuordnung eingeschränkt wird, kann eine dedizierte AMD-Physikmaschine als Betriebsoption prüfen. Sie ersetzt weder Sicherung noch Hochverfügbarkeit; diese müssen weiterhin eigenständig geplant und getestet werden. Vor einer Entscheidung sollten die tatsächlichen Speicheranforderungen, das gewünschte Betriebssystem und der Abrechnungszeitraum anhand der Produktübersicht von XFP Cloud geprüft werden. Für längerfristige Systeme ist außerdem zu klären, wie die gewählte Zahlungsperiode zur geplanten Nutzung passt; die Abrechnungsinformationen liefern dafür den passenden Bezug.

Häufige Fragen

1. Wie gelingt der Wechsel einer n8n-Instanz von SQLite zu PostgreSQL?

   Der Datenbankwechsel allein über Konfigurationswerte überträgt keine vorhandenen Datensätze. Sichern Sie zuerst die bisherige Instanz samt erforderlicher Dateien und Schlüssel. Legen Sie anschließend fest, welche Daten übernommen werden müssen, und prüfen Sie für Ihre installierte n8n-Version die offizielle Dokumentation. Importieren Sie unterstützte Objekte auf einer Testkopie und kontrollieren Sie den Betrieb vor der Umschaltung.

2. Bleiben Workflows und Zugangsdaten beim Wechsel der n8n-Datenbank erhalten?

   Sie können Workflows und Zugangsdaten über die dokumentierten CLI-Funktionen exportieren und importieren. Das bedeutet jedoch nicht, dass der Datenbankwechsel sie automatisch kopiert. Prüfen Sie vor dem Import die Auswirkungen möglicher ID-Überschreibungen und bewahren Sie den für die Verschlüsselung relevanten Schlüssel auf. Testen Sie danach, ob Workflows und Zugangsdaten in der Zielinstanz korrekt verfügbar sind.

3. Muss die Ausführungshistorie bei einer n8n-Datenbankmigration mit umziehen?

   Das hängt davon ab, ob die Historie für Nachvollziehbarkeit, Fehleranalyse oder interne Anforderungen benötigt wird. Sie ist nicht mit dem Export von Workflows und Zugangsdaten gleichzusetzen. Bevor Sie sie übertragen, müssen Sie eine für Ihre Version passende Methode und die Vollständigkeit der Einträge prüfen. Ohne verifizierten Migrationsweg sollten Sie nicht annehmen, dass die Historie vollständig übernommen wird.

4. Was sollte vor einem Upgrade auf n8n 2.x zusätzlich geprüft werden?

   Behandeln Sie Datenbankumzug und Versionsupgrade als getrennte Änderungen. Lesen Sie die offiziellen Hinweise zu Änderungen und den Migrationsbericht für das konkrete Ziel. Prüfen Sie die Datenbankmigration zunächst mit der installierten Version und nehmen Sie das Upgrade danach separat ab. So lässt sich ein Fehler besser einer Änderung zuordnen, und die ursprüngliche Datenbankkopie bleibt als Rückweg verfügbar.