N8N_DATA_TABLES_MAX_SIZE_BYTES est la limite pour la taille totale de toutes les tables de données dans une instance n8n. La valeur par défaut est 50 MB.
J’aimerais une recommandation sur la possibilité d’augmenter cette limite dans un environnement auto-hébergé avec une base de données Postgres. Est-ce que plusieurs Go sont réalistes ?
Quel est le message d’erreur (le cas échéant) ?
non applicable - demande de recommandation de configuration
Veuillez partager votre workflow
non applicable - demande de recommandation de configuration
Partagez la sortie retournée par le dernier nœud
non applicable - demande de recommandation de configuration
Bienvenue dans la communité n8n @Tomasz_Traczyk
Selon le discobot de la communauté, il n’y a pas de limite pratique stricte définie pour N8N_DATA_TABLES_MAX_SIZE_BYTE, car la limite réelle dépend de la capacité de stockage et des performances de votre base de données Postgres et de la mémoire disponible sur le serveur. La valeur par défaut est 50 MB, mais dans les configurations auto-hébergées avec Postgres, il est viable d’augmenter à plusieurs Go si l’infrastructure le permet, comme discuté dans les questions de la communauté.
Il est recommandé de surveiller l’utilisation du disque et de la mémoire, car les très grandes tables peuvent affecter la vitesse des requêtes et le temps d’exécution des workflows. Augmentez progressivement et testez la stabilité du système.
Techniquement, vous pouvez augmenter la limite à plusieurs gigaoctets car votre base de données Postgres peut gérer cette quantité de données sans aucun problème. Cependant, le fait que la base de données puisse la stocker ne signifie pas que n8n peut l’afficher. La fonctionnalité « Data Tables » intégrée est conçue pour de petites à moyennes quantités d’informations, pas pour des ensembles de données massifs.
Le véritable problème est votre navigateur web. Si vous stockez des gigaoctets de données dans ces tableaux, l’éditeur n8n risque de devenir très lent, de se bloquer ou même de planter lorsque vous essayez d’ouvrir ou de modifier le tableau. Vous pouvez également rencontrer des erreurs de « timeout » où la page ne se charge pas car elle essaie de traiter trop d’informations à la fois.
Si vous avez vraiment besoin de stocker plusieurs gigaoctets de données, la meilleure solution est de créer un tableau standard directement dans votre base de données Postgres et d’utiliser le « Postgres Node » pour le gérer. Cela garde le travail lourd à l’intérieur de la base de données et loin de votre navigateur, en garantissant que votre instance n8n reste rapide et stable au fur et à mesure que vos données augmentent.
Je ne pense pas que cette préoccupation soit justifiée. Les API des tableaux de données sont paginées, donc même un grand tableau ne devrait pas exercer beaucoup de pression sur le navigateur.
De plus, ce que je demande, c’est la limite globale. Une limite globale élevée et un grand volume total de données n’impliquent pas automatiquement des tailles de tableau individuelles importantes.
J’aimerais conserver la ségrégation du contrôle d’accès côté application entre les projets, et utiliser l’interface CRUD qu’offre nativement Data Tables dans n8n.
Le nœud Postgres ne me donne ni l’un ni l’autre ; c’est pourquoi j’ai voulu explorer les limitations pratiques des Data Tables, et voir si quelqu’un a de l’expérience en les utilisant à grande échelle, ou si je peux obtenir des recommandations officielles des mainteneurs.
Augmenter la limite de stockage à plusieurs gigaoctets est tout à fait réalisable et sûr pour votre configuration. Comme vous avez besoin de l’interface utilisateur intégrée et de la capacité à garder les données séparées par projet, continuer à utiliser les Data Tables de n8n est le bon choix. Votre base de données Postgres est conçue pour gérer ce volume de données sans aucun problème.
Techniquement, n8n ne « surcharge » pas le système pour vérifier la limite globale. Il demande simplement à Postgres l’espace disque total utilisé par les tables, ce qui est une opération quasi instantanée, quel que soit le volume de données que vous avez. De plus, parce que l’interface charge les données par petites pages (pagination), avoir une énorme quantité de données au total ne ralentira pas votre navigateur ni ne bloquera l’application.
Le seul véritable risque n’est pas la taille totale de vos tables, mais la taille d’une seule entrée. Bien que la liste des lignes soit paginée, le contenu d’une seule cellule ne l’est pas. Si un workflow enregistre accidentellement une énorme quantité de texte (comme une grande page HTML ou un énorme fichier JSON) dans une cellule, le navigateur peut se bloquer ou s’arrêter quand vous essayez d’ouvrir cette ligne particulière.
Pour que tout continue à fonctionner correctement, allez-y et augmentez la limite à la taille souhaitée. Assurez-vous simplement que vos workflows n’enregistrent pas des blobs de texte excessivement volumineux dans des cellules uniques. Si vous remarquez que le système ralentit pendant les périodes de fort trafic, vous pouvez simplement augmenter la taille du pool de connexions à la base de données dans vos paramètres pour gérer plus de requêtes simultanées.
Oui, plusieurs GB est réalisable sur un Postgres auto-hébergé. La valeur par défaut de 50MB n’est qu’une barrière au niveau de l’application, les données vivent dans Postgres, qui n’a aucun problème avec ce volume. C’est assez scalable.
Quelques considérations pratiques :
La limite contrôle en réalité le stockage total sur toutes les tables de données de l’instance, pas par table. Quand vous atteignez 80% de la limite, n8n affiche un avertissement. À 100%, les opérations d’écriture commencent à échouer dans les workflows. Donc fixez-la plus haut que votre utilisation réelle attendue avec une marge.
Pour l’augmenter, ajoutez cette variable d’environnement à votre configuration n8n :
N8N_DATA_TABLES_MAX_SIZE_BYTES=2147483648
C’est 2GB. Ajustez selon vos besoins.
Concernant les performances, c’est plus important que la limite de taille. Les tables de données de n8n utilisent Postgres sous le capot mais n8n gère sa propre couche de requêtes. Pour des insertions simples et des recherches de clés, plusieurs GB c’est correct en pratique. Si vous faites quoi que ce soit qui ressemble à une recherche, un filtrage ou une agrégation sur de grandes données dans un workflow, vous le sentirez. n8n n’optimise pas ces requêtes comme le ferait une table Postgres correctement indexée. Pour quelques GB de données de référence que vous lisez surtout, probablement ok. Pour quoi que ce soit avec beaucoup d’écritures ou beaucoup de requêtes complexes à cette échelle, je garderais les données dans une table Postgres appropriée et les interrogerais directement avec le nœud Postgres.
En gros, fixez la limite, surveillez l’avertissement dans l’interface utilisateur, et observez les performances des requêtes dans vos workflows à mesure que les données augmentent. Pour plusieurs GB de données surtout en lecture vous serez probablement ok.
Plusieurs GB est tout à fait réalisable avec Postgres. La limite par défaut de 50 MB est juste une sécurité pour éviter les accidents, ce n’est pas un reflet de ce que la base de données peut réellement gérer.
Avec une configuration Postgres auto-hébergée, une approche raisonnable consiste à fixer la limite à environ 25 % de l’espace disque disponible sur le volume Postgres. Donc si vous avez un volume de données de 40 GB, quelque chose comme 10 GB (10737418240 en bytes) est un plafond sûr.
En pratique, 2-5 GB couvre la plupart des cas d’usage auto-hébergés intensifs. Si vous stockez de grands ensembles de données ou effectuez une journalisation à haut volume dans les tables, vous pourriez monter vers 10 GB ou plus, mais à ce stade il vaut la peine de vérifier les performances des requêtes Postgres à mesure que les tables augmentent. Les analyses de tables volumineuses non indexées ralentiront les choses avant que l’espace disque ne devienne le problème.
Une chose à surveiller une fois que vous augmentez la limite : utilisez SELECT pg_size_pretty(pg_total_relation_size('n8n_data_table')) dans Postgres pour suivre la croissance réelle au fil du temps. Cela vous indique si vous avez défini le plafond assez haut ou si vous vous en rapprochez plus vite que prévu.
La réponse courte : oui, plusieurs GB, c’est très bien. Définissez-le selon ce qui convient à votre disque, puis surveillez la croissance réelle.
Il n’y a pas de limite stricte dans n8n lui-même, la limite pratique dépend de vos ressources Postgres et serveur, donc plusieurs GB sont réalisables mais le chiffre est moins important que la façon dont vous utilisez les tables.
La vraie contrainte est la performance des requêtes, pas la taille brute. Les tables de données conviennent bien comme magasin clé-valeur ou de lookup à l’échelle des GB sur Postgres, mais si un workflow lit de gros volumes d’une table de plusieurs GB en mémoire à chaque exécution, vous rencontrerez des problèmes de RAM et de latence bien avant d’atteindre une limite de stockage. Augmentez donc la limite pour correspondre à votre disque (plusieurs GB est raisonnable sur un VPS décent), mais concevez vos lectures pour extraire uniquement les lignes dont vous avez besoin, indexées, plutôt que de scanner la table entière à chaque exécution.
Si vous poussez vers plusieurs GB de données opérationnelles, c’est généralement le signe que les données méritent leur propre table Postgres que vous interrogerez directement avec le nœud Postgres, plutôt que les tables de données n8n, qui sont destinées à un état de workflow plus léger. Ce que vous stockez dedans détermine si augmenter la limite ou déplacer les données est le meilleur choix.