SQLite oder PostgreSQL: wann der Wechsel fällig ist

n8n startet standardmäßig mit SQLite, einer Dateidatenbank ohne eigenen Serverprozess, die keine separate Installation braucht. Für Testinstanzen, einzelne Automatisierungen und den Einstieg reicht das aus. Sobald Sie aber mehrere gleichzeitige Workflow-Ausführungen fahren, den Queue-Modus einsetzen oder mehrere Main-Instanzen betreiben wollen, rät n8n in der eigenen Dokumentation ausdrücklich zu PostgreSQL ab Version 13. Der richtige Zeitpunkt für den Wechsel hängt weniger an einer festen Nutzerzahl als an drei Faktoren: Anzahl gleichzeitiger Ausführungen, geplante Architektur und wie oft bereits Sperrfehler in den Logs auftauchen. Stand: Juli 2026.

Symptome, dass SQLite an ihre Grenzen kommt

In der n8n-Community taucht ein Fehlerbild immer wieder auf: SQLITE_BUSY: database is locked. Die Ursache liegt im Design von SQLite, das pro Datei nur einen schreibenden Zugriff gleichzeitig zulässt. Laufen mehrere Workflows parallel oder öffnen Sie während aktiver Ausführungen den Editor, kollidieren die Schreibzugriffe auf dieselbe Datei. Kurzfristig hilft der WAL-Modus (Write-Ahead Logging) mit einem Busy-Timeout von mindestens 5000 Millisekunden, das reduziert die Fehlerhäufigkeit. Die zugrunde liegende Ein-Schreiber-Beschränkung bleibt davon aber unberührt und kehrt bei steigender Last zuverlässig zurück.

Die Schwellenwerte, die n8n selbst nennt

n8n gibt in der Dokumentation keine feste Executions-pro-Tag-Zahl als Umschaltpunkt an, macht die Grenze aber an konkreten Architekturentscheidungen fest.

• Queue-Modus geplant: Für den produktiven Queue-Betrieb schreibt n8n direkt, dass der Ausführungsmodus queue mit einer SQLite-Datenbank nicht empfohlen wird. Sobald Worker-Prozesse parallel auf dieselbe Datenbank schreiben, braucht es Postgres.
• Mehrere Main-Instanzen (Multi-Main): Für Hochverfügbarkeit mit mehreren Main-Prozessen verlangt n8n ausdrücklich eine Verbindung zu Postgres und Redis, SQLite ist dafür nicht vorgesehen.
• Worker-Konkurrenz: Der Concurrency-Wert pro Worker liegt standardmäßig bei 10, n8n empfiehlt mindestens 5. Bei vielen Workern mit niedriger Konkurrenz drohen laut Dokumentation ausgeschöpfte Datenbankverbindungen, ein Zustand, den eine Ein-Datei-Datenbank ohne echten Verbindungspool strukturell schlecht abfedert.
• Referenzwert aus dem Benchmark: In den offiziellen Performance-Tests erreicht eine Einzelinstanz mit Postgres-Backend bis zu 220 Workflow-Ausführungen pro Sekunde. Das ist kein SQLite-Grenzwert, zeigt aber, für welche Lastklasse Postgres in n8n ausgelegt ist.
• Signal aus n8n Cloud: Selbst im eigenen Cloud-Produkt bleibt Postgres den Enterprise-Scaling-Tarifen vorbehalten, alle kleineren Stufen laufen auf SQLite. Das spiegelt ungefähr, ab wann n8n den Umstieg selbst für nötig hält.

Migrationsschritte von SQLite zu PostgreSQL

Der Wechsel läuft über Export und Import, nicht über eine automatische Konvertierung der Datenbankdatei.

• PostgreSQL vorbereiten: Postgres 13 oder neuer bereitstellen, eine eigene Datenbank und einen dedizierten Benutzer mit vollen Rechten darauf anlegen.
• Workflows und Credentials exportieren: Über die CLI mit n8n export:workflow --all --output=backup/ und n8n export:credentials --all --decrypted --output=backup/ sichern. Das entschlüsselte Credentials-Backup gehört danach sofort in einen geschützten, nicht öffentlich zugänglichen Speicherort.
• Umgebungsvariablen umstellen: DB_TYPE auf postgresdb setzen sowie Host, Port, Datenbankname, Benutzer, Passwort und optional das Schema über die passenden DB_POSTGRESDB-Variablen konfigurieren.
• n8n gegen die leere Postgres-Datenbank starten: n8n legt das benötigte Schema beim ersten Start selbst an, ein manuelles Anlegen von Tabellen ist nicht nötig.
• Daten zurückspielen: Mit n8n import:workflow --separate --input=backup/ und n8n import:credentials --separate --input=backup/ die gesicherten Stände einspielen und Workflows anschließend stichprobenartig testen.

Aufwand und Grenzen des Wechsels

Der Umstieg ist kein Ein-Klick-Vorgang, sondern ein kleines Wartungsfenster: Während Export, Umstellung und Import steht n8n kurz still, und ausführliche Execution-Historien werden über den Standardweg nicht automatisch mitmigriert. Für kleine Installationen mit wenigen Workflows ist der Aufwand überschaubar, für gewachsene Instanzen mit vielen aktiven Automatisierungen lohnt sich vorheriges Testen auf einer Staging-Instanz. Wer diesen Schritt im laufenden Betrieb nicht allein verantworten möchte, kann ihn auch extern begleiten lassen, etwa im Rahmen einer n8n-Beratung mit Festpreis.

Häufige Fragen zu SQLite und PostgreSQL bei n8n

Ab wie vielen Ausführungen pro Tag muss ich zu PostgreSQL wechseln?

Eine pauschale Zahl nennt n8n nicht. Entscheidend ist laut Dokumentation eher die Architektur: Sobald Queue-Modus oder mehrere Main-Instanzen geplant sind, gilt Postgres als Voraussetzung, unabhängig vom genauen Execution-Volumen.

Kann ich SQLite einfach weiterlaufen lassen und nur den Busy-Timeout erhöhen?

Für kleine, wenig parallele Instanzen ja, das kann Sperrfehler spürbar reduzieren. Sobald Sie aber in Richtung Queue-Modus oder Multi-Main wechseln, reicht diese Anpassung laut n8n nicht mehr aus.

Gehen bei der Migration Daten verloren?

Der Standardweg über Export und Import überträgt Workflows und Credentials zuverlässig. Vollständige Execution-Historien sind darin nicht automatisch enthalten, wer sie braucht, sollte das vor der Migration gesondert prüfen.

Brauche ich für PostgreSQL zwingend den Queue-Modus?

Nein. Sie können PostgreSQL auch im Single-Main-Betrieb ohne Queue-Modus nutzen, etwa um Lock-Fehler zu vermeiden. Queue-Modus und Multi-Main sind eigene Ausbaustufen, die zusätzlich Redis voraussetzen.

Weitere Details zur Datenbankwahl und zu den Umgebungsvariablen finden Sie in der n8n-Dokumentation zur Datenbankauswahl sowie in der Anleitung zum Queue-Modus.