N8N_DATA_TABLES_MAX_SIZE_BYTES ist das Limit für die Gesamtgröße aller Datentabellen in einer n8n-Instanz. Der Standard ist 50 MB.
Ich möchte eine Empfehlung, wie weit es praktikabel ist, diesen Wert in einer selbstgehosteten Umgebung mit einer Postgres-Datenbank zu erhöhen. Sind mehrere GB machbar?
Was ist die Fehlermeldung (falls vorhanden)?
Nicht zutreffend – ich frage nach einer Konfigurationsempfehlung
Bitte teilen Sie Ihren Workflow
Nicht zutreffend – ich frage nach einer Konfigurationsempfehlung
Ausgabe des letzten Knotens freigeben
Nicht zutreffend – ich frage nach einer Konfigurationsempfehlung
Nach dem Discobot hier in der Community gibt es kein praktisches hartes Limit für N8N_DATA_TABLES_MAX_SIZE_BYTE, da das tatsächliche Limit von der Speicherkapazität und Leistung deiner Postgres-Datenbank sowie dem verfügbaren Speicher auf dem Server abhängt. Der Standardwert liegt bei 50 MB, aber in selbstgehosteten Setups mit Postgres ist es durchaus machbar, auf mehrere GB zu erhöhen, wenn die Infrastruktur dies unterstützt, wie in Community-Fragen diskutiert.
Es wird empfohlen, die Festplatte und den Speichernutzung zu überwachen, da sehr große Tabellen die Geschwindigkeit von Abfragen und die Ausführungszeit von Workflows beeinträchtigen können. Passe die Werte schrittweise an und teste die Stabilität deines Systems.
Technisch gesehen kannst du das Limit auf mehrere Gigabyte erhöhen, da deine Postgres-Datenbank diese Menge problemlos verarbeiten kann. Aber nur weil die Datenbank die Daten speichern kann, heißt das nicht, dass n8n sie anzeigen kann. Die integrierte Funktion „Data Tables
Ich denke nicht, dass diese Bedenken berechtigt sind. Die Data Tables APIs sind paginiert, daher sollte selbst eine große Tabelle nicht viel Druck auf den Browser ausüben.
Darüber hinaus geht es mir um das globale Limit. Ein hohes globales Limit und ein großes Gesamtdatenvolumen bedeuten nicht automatisch große einzelne Tabellengrößen.
[quote=“kjooleng, post:3, topic:297897”]
Wenn du wirklich mehrere Gigabytes an Daten speichern musst, ist die beste Lösung, eine Standard-Tabelle direkt in deiner Postgres-Datenbank zu erstellen und den „Postgres Node
Die Erhöhung des Speicherlimits auf mehrere Gigabyte ist für dein Setup völlig machbar und sicher. Da du die integrierte Benutzeroberfläche benötigst und die Möglichkeit, Daten nach Projekt zu trennen, ist die Fortsetzung der Nutzung von n8ns Data Tables die richtige Wahl. Deine Postgres-Datenbank ist dafür ausgelegt, dieses Datenvolumen ohne Probleme zu verarbeiten.
Ja, mehrere GB sind auf selbstgehostem Postgres machbar. Die 50MB-Standardeinstellung ist nur eine Schutzmaßnahme auf Anwendungsebene, die Daten liegen in Postgres, das mit diesem Volumen kein Problem hat. Es ist ziemlich skalierbar.
Ein paar praktische Überlegungen:
Das Limit kontrolliert tatsächlich den Gesamtspeicher über alle Datentabellen in der Instanz, nicht pro Tabelle. Wenn du 80% des Limits erreichst, zeigt n8n eine Warnung an. Bei 100% beginnen Schreibvorgänge in Workflows zu fehlschlagen. Lege es also höher fest als deine erwartete tatsächliche Nutzung mit etwas Puffer.
Um es zu erhöhen, füge diese Umgebungsvariable zu deiner n8n-Konfiguration hinzu:
N8N_DATA_TABLES_MAX_SIZE_BYTES=2147483648
Das sind 2GB. Passe es nach Bedarf an.
Bezüglich Leistung ist dies wichtiger als das Größenlimit. n8n’s Datentabellen verwenden Postgres im Hintergrund, aber n8n verwaltet eine eigene Abfrageschicht. Für einfache Einfügungen und Schlüsselabfragen sind mehrere GB in der Praxis kein Problem. Wenn du etwas machst, das einer Suche, einem Filter oder einer Aggregation über große Datenmengen in einem Workflow ähnelt, wirst du das spüren. n8n optimiert diese Abfragen nicht so, wie eine richtig indizierte Postgres-Tabelle es würde. Für einige GB an Referenzdaten, die du hauptsächlich liest, ist das wahrscheinlich in Ordnung. Für anything schreibintensiv oder komplex-abfrageintensiv in diesem Maßstab würde ich die Daten in einer richtigen Postgres-Tabelle halten und sie direkt mit dem Postgres-Node abfragen.
Im Grunde genommen: Stelle das Limit ein, überwache die Warnung in der UI und beobachte die Abfrageleistung in deinen Workflows, während die Daten wachsen. Für mehrere GB hauptsächlich gelesener Daten wirst du wahrscheinlich in Ordnung sein.
Mehrere GB sind mit Postgres vollkommen machbar, die 50-MB-Standardeinstellung ist nur eine Sicherheitsobergrenze, um Unfälle zu verhindern, spiegelt aber nicht wider, was die Datenbank tatsächlich verarbeiten kann.
Bei einem selbst gehosteten Postgres-Setup ist ein vernünftiger Ansatz, das Limit auf etwa 25% des verfügbaren Speicherplatzes auf dem Postgres-Volume zu setzen. Wenn du also ein 40-GB-Datenvolumen hast, ist etwas wie 10 GB (10737418240 in Bytes) eine sichere Obergrenze.
In der Praxis decken 2–5 GB die meisten intensiven Fälle für selbst gehostete Umgebungen ab. Wenn du große Datensätze speicherst oder ein hohes Volumen an Protokollierung in Tabellen durchführst, könntest du auf 10 GB+ hinarbeiten, aber an diesem Punkt lohnt es sich, die Postgres-Abfrageleistung zu überprüfen, während die Tabellen wachsen – große unindexierte Tabellenscans werden die Dinge verlangsamen, bevor Speicherplatz zum Problem wird.
Etwas, das es wert ist zu überwachen, sobald du das Limit erhöhst: Verwende SELECT pg_size_pretty(pg_total_relation_size('n8n_data_table')) in Postgres, um das tatsächliche Wachstum im Laufe der Zeit zu verfolgen. Das zeigt dir, ob du die Obergrenze hoch genug gesetzt hast oder ob du schneller als erwartet darauf zugehst.
Die kurze Antwort: Ja, mehrere GB sind in Ordnung. Setze es auf das, was für deine Festplatte sinnvoll ist, und beobachte dann das tatsächliche Wachstum.
In n8n selbst gibt es keine harte Obergrenze, die praktische Grenze ist deine Postgres- und Server-Ressourcen, daher sind mehrere GB machbar, aber die konkrete Zahl ist weniger wichtig als die Nutzung der Tabellen.
Die eigentliche Einschränkung ist die Abfrageleistung, nicht die rohe Größe. Datentabellen funktionieren gut als Key-Value- oder Lookup-Speicher im GB-Bereich auf Postgres, aber wenn ein Workflow bei jeder Ausführung große Teile einer Multi-GB-Tabelle in den Speicher lädt, wirst du auf RAM- und Latenzprobleme stoßen, lange bevor du eine Speichergrenze erreichst. Erhöhe also die Grenze, um sie deiner Festplatte anzupassen (mehrere GB sind auf einem anständigen VPS angemessen), aber gestalte Lesevorgänge so, dass nur die benötigten Zeilen abgerufen werden – indiziert – anstatt die ganze Tabelle bei jedem Durchlauf zu durchsuchen.
Wenn du mehrere GB an Betriebsdaten speicherst, ist das normalerweise ein Zeichen dafür, dass die Daten ihre eigene Postgres-Tabelle benötigen, die du direkt mit dem Postgres-Node abfragst, anstatt n8n-Datentabellen zu verwenden, die für leichtere Workflow-Zustände vorgesehen sind. Was speicherst du dort – das entscheidet, ob die Erhöhung der Grenze oder das Verschieben der Daten die bessere Lösung ist.