Warum die n8n-Datenbank wächst: Execution-Daten aufräumen

n8n speichert bei jedem Workflow-Lauf Execution-Daten in der eigenen Datenbank, und ohne Aufräumen wächst diese Datenbank bei aktiven Workflows oft schnell auf mehrere Gigabyte an. Die Lösung heißt Execution Data Pruning: n8n löscht abgeschlossene Executions automatisch, sobald sie älter als eine festgelegte Anzahl Stunden sind oder die Gesamtzahl gespeicherter Executions ein Limit überschreitet. Gesteuert wird dieses Verhalten über Umgebungsvariablen wie EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE und EXECUTIONS_DATA_PRUNE_MAX_COUNT, die bei selbst gehosteten n8n-Instanzen direkt in der Konfiguration gesetzt werden. Stand: Juli 2026.

Warum wächst die n8n-Datenbank durch Executions so schnell?

Jede Ausführung eines Workflows erzeugt einen Datensatz mit Input, Output und Status jedes einzelnen Knotens, und bei mehreren hundert Läufen pro Tag summiert sich das rasch zu einer erheblichen Datenmenge. n8n speichert dabei standardmäßig sowohl erfolgreiche als auch fehlgeschlagene Ausführungen von veröffentlichten Workflows sowie manuelle Testläufe aus dem Editor. Wer viele Workflows mit hoher Trigger-Frequenz betreibt, etwa stündliche Synchronisationen oder Webhook-gesteuerte Prozesse, merkt das Wachstum besonders deutlich an Ladezeiten der Executions-Liste und an der Größe der Datenbankdatei. Laut der offiziellen n8n-Dokumentation ist Pruning deshalb standardmäßig aktiviert, damit die Datenbank nicht unkontrolliert wächst.

Was bewirkt die Einstellung EXECUTIONS_DATA_PRUNE genau?

EXECUTIONS_DATA_PRUNE ist ein boolescher Schalter mit dem Standardwert true, der festlegt, ob n8n abgeschlossene Executions überhaupt automatisch löscht. Ist die Variable aktiv, markiert n8n alte Executions zunächst zur Löschung (Soft Delete) und entfernt sie anschließend endgültig (Hard Delete). Dieses zweistufige Vorgehen dient laut Dokumentation der Performance, weil das eigentliche Löschen im Hintergrund erfolgt, ohne den laufenden Betrieb zu blockieren. Details zum genauen Ablauf beschreibt die n8n-Dokumentation zur Verwaltung von Execution-Daten.

Welche Umgebungsvariablen bestimmen, wie lange Daten aufbewahrt werden?

Pruning greift, sobald eine von zwei Bedingungen erfüllt ist: das Alter einer Execution überschreitet ein Limit, oder die Gesamtzahl gespeicherter Executions überschreitet ein Limit. Die relevanten Variablen sind in der Executions-Referenz dokumentiert.

• EXECUTIONS_DATA_MAX_AGE: Alter in Stunden, ab dem eine abgeschlossene Execution zur Löschung markiert wird, Standardwert 336 Stunden, also 14 Tage.
• EXECUTIONS_DATA_PRUNE_MAX_COUNT: maximale Anzahl an Executions, die in der Datenbank verbleiben sollen, Standardwert 10.000, der Wert 0 bedeutet kein Limit.
• EXECUTIONS_DATA_HARD_DELETE_BUFFER: Sicherheitspuffer in Stunden, Standardwert 1, der ganz frisch abgeschlossene Daten bewusst noch von der endgültigen Löschung ausnimmt, damit sie für die Fehlersuche verfügbar bleiben.
• EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL / EXECUTIONS_DATA_PRUNE_SOFT_DELETE_INTERVAL: wie oft in Minuten der jeweilige Löschlauf startet, Standardwerte 15 beziehungsweise 60 Minuten.

Bei SQLite als Datenbank gibt die Dokumentation zusätzlich einen wichtigen Hinweis: Der durch Pruning freigewordene Speicherplatz wird von SQLite intern wiederverwendet, aber nicht automatisch an das Betriebssystem zurückgegeben. Um den Speicherplatz tatsächlich freizugeben, empfiehlt n8n entweder die Umgebungsvariable DB_SQLITE_VACUUM_ON_STARTUP zu setzen oder den VACUUM-Befehl manuell auszuführen.

Welche Executions werden nie automatisch gelöscht?

Nicht jede Execution unterliegt der Bereinigung. Executions mit dem Status new, running oder waiting sind laut Dokumentation von der Löschung ausgenommen, weil sie noch nicht abgeschlossen sind. Zusätzlich bleiben annotierte Executions dauerhaft erhalten, also solche, die im Editor mit Tags oder einer Bewertung versehen wurden. Das ist praktisch, um einzelne wichtige Testläufe oder auffällige Fehler gezielt vor dem automatischen Löschen zu schützen, ohne das gesamte Pruning zu deaktivieren.

Wie legen Sie pro Workflow fest, was überhaupt gespeichert wird?

Bevor Pruning überhaupt greift, entscheidet die Workflow-Einstellung, ob eine Execution gespeichert wird. Im Workflow-Editor öffnen Sie dazu über das Drei-Punkte-Menü oben rechts den Punkt Settings und legen dort separat fest, ob fehlgeschlagene, erfolgreiche und manuelle Executions gespeichert werden sollen. Zusätzlich steuert die Option Save execution progress, ob n8n den Zustand jedes einzelnen Knotens während des Laufs sichert, was laut Dokumentation die Latenz erhöhen kann, dafür aber einen Neustart an der Fehlerstelle ermöglicht. Für produktive Workflows mit hohem Volumen lohnt es sich, genau zu prüfen, welche Executions wirklich langfristig relevant sind, bevor man an den globalen Prune-Variablen schraubt. Bei der n8n-Automatisierung von NordFlux gehört diese Konfiguration serverseitig zur Grundeinrichtung, damit die Datenbank eines selbst gehosteten Systems dauerhaft performant bleibt und die Datenhoheit beim Kunden liegt.

Häufige Fragen zu n8n Execution Data Pruning

Was passiert, wenn ich EXECUTIONS_DATA_PRUNE deaktiviere?

Steht die Variable auf false, löscht n8n keine Executions mehr automatisch, und die Datenbank wächst unbegrenzt weiter. Das kann für kurze Testphasen oder Debugging sinnvoll sein, ist im Dauerbetrieb aber riskant, weil die Datenbankdatei irgendwann Performance und Speicherplatz an ihre Grenzen bringt. Für produktive Instanzen empfiehlt sich, Pruning aktiviert zu lassen und stattdessen EXECUTIONS_DATA_MAX_AGE sowie EXECUTIONS_DATA_PRUNE_MAX_COUNT an den eigenen Bedarf anzupassen.

Wie schnell verschwinden abgeschlossene Executions nach dem Prune-Limit tatsächlich aus der Datenbank?

Das hängt von den konfigurierten Intervallen ab, standardmäßig prüft n8n alle 60 Minuten auf Soft-Delete-Kandidaten und führt alle 15 Minuten den endgültigen Hard-Delete aus. Zusätzlich sorgt der Hard-Delete-Puffer von standardmäßig einer Stunde dafür, dass ganz frisch abgeschlossene Executions nicht sofort verschwinden. In der Praxis dauert es also je nach Konfiguration bis zu wenigen Stunden, bis eine Execution die Datenbank tatsächlich verlassen hat.

Kann ich einzelne wichtige Executions vor dem automatischen Löschen schützen?

Ja, annotierte Executions, also solche mit Tags oder einer Bewertung im n8n-Editor, sind laut Dokumentation von der automatischen Bereinigung ausgenommen. Das eignet sich, um einzelne auffällige Fehlerfälle oder Referenzläufe dauerhaft nachvollziehbar zu halten, ohne das globale Pruning zu deaktivieren. Für die breite Masse an Routine-Executions bleibt die automatische Löschung trotzdem aktiv.

Muss ich bei SQLite nach dem Pruning noch etwas manuell tun?

Ja, denn SQLite gibt gelöschten Speicherplatz nicht automatisch an das Betriebssystem zurück, sondern verwendet ihn intern für künftige Executions weiter. Wer den Speicherplatz auf der Festplatte tatsächlich reduzieren möchte, sollte laut n8n-Dokumentation entweder DB_SQLITE_VACUUM_ON_STARTUP setzen oder den VACUUM-Befehl gelegentlich manuell ausführen. Bei PostgreSQL als Datenbank stellt sich dieses Problem in der Regel weniger stark, da dessen Speicherverwaltung anders funktioniert.