Pourquoi la base de données n8n grossit : nettoyer les données d'exécution

À chaque exécution d'un workflow, n8n enregistre des données d'exécution dans sa propre base de données, et sans nettoyage, cette base de données atteint souvent rapidement plusieurs gigaoctets pour des workflows actifs. La solution s'appelle Execution Data Pruning : n8n supprime automatiquement les executions terminées dès qu'elles dépassent un nombre d'heures défini ou que le nombre total d'executions stockées dépasse une limite. Ce comportement est contrôlé via des variables d'environnement telles que EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE et EXECUTIONS_DATA_PRUNE_MAX_COUNT, qui sont définies directement dans la configuration pour les instances n8n auto-hébergées. Mise à jour : juillet 2026.

Pourquoi la base de données n8n grossit-elle si vite à cause des executions ?

Chaque exécution d'un workflow génère un enregistrement contenant l'input, l'output et le statut de chaque nœud, et avec plusieurs centaines d'exécutions par jour, cela représente rapidement un volume de données considérable. Par défaut, n8n enregistre aussi bien les exécutions réussies qu'échouées des workflows publiés, ainsi que les tests manuels effectués depuis l'éditeur. Quiconque exploite de nombreux workflows avec une fréquence de déclenchement élevée, par exemple des synchronisations horaires ou des processus pilotés par webhook, remarque particulièrement cette croissance dans les temps de chargement de la liste des executions et dans la taille du fichier de base de données. Selon la documentation officielle de n8n, le pruning est donc activé par défaut afin que la base de données ne croisse pas de manière incontrôlée.

Que fait exactement le paramètre EXECUTIONS_DATA_PRUNE ?

EXECUTIONS_DATA_PRUNE est un interrupteur booléen dont la valeur par défaut est true, qui détermine si n8n supprime automatiquement les executions terminées. Si la variable est active, n8n marque d'abord les anciennes executions pour suppression (soft delete), puis les supprime définitivement (hard delete). Selon la documentation, cette approche en deux étapes sert la performance, car la suppression proprement dite s'effectue en arrière-plan sans bloquer le fonctionnement en cours. Les détails du déroulement exact sont décrits dans la documentation n8n sur la gestion des données d'exécution.

Quelles variables d'environnement déterminent la durée de conservation des données ?

Le pruning s'applique dès que l'une des deux conditions suivantes est remplie : l'âge d'une execution dépasse une limite, ou le nombre total d'executions stockées dépasse une limite. Les variables concernées sont documentées dans la référence des executions.

• EXECUTIONS_DATA_MAX_AGE : âge en heures à partir duquel une execution terminée est marquée pour suppression, valeur par défaut 336 heures, soit 14 jours.
• EXECUTIONS_DATA_PRUNE_MAX_COUNT : nombre maximal d'executions devant rester dans la base de données, valeur par défaut 10 000, la valeur 0 signifie aucune limite.
• EXECUTIONS_DATA_HARD_DELETE_BUFFER : tampon de sécurité en heures, valeur par défaut 1, qui exclut délibérément les données terminées très récemment de la suppression définitive afin qu'elles restent disponibles pour le dépannage.
• EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL / EXECUTIONS_DATA_PRUNE_SOFT_DELETE_INTERVAL : fréquence, en minutes, à laquelle chaque cycle de suppression démarre, valeurs par défaut respectivement 15 et 60 minutes.

Pour SQLite comme base de données, la documentation donne une remarque importante supplémentaire : l'espace disque libéré par le pruning est réutilisé en interne par SQLite, mais n'est pas automatiquement restitué au système d'exploitation. Pour réellement libérer l'espace disque, n8n recommande soit de définir la variable d'environnement DB_SQLITE_VACUUM_ON_STARTUP, soit d'exécuter manuellement la commande VACUUM.

Quelles executions ne sont jamais supprimées automatiquement ?

Toutes les executions ne sont pas soumises au nettoyage. Selon la documentation, les executions avec le statut new, running ou waiting sont exclues de la suppression car elles ne sont pas encore terminées. De plus, les executions annotées, c'est-à-dire celles auxquelles des tags ou une évaluation ont été attribués dans l'éditeur, sont conservées de façon permanente. Cela permet de protéger de manière ciblée certains tests importants ou erreurs notables de la suppression automatique, sans désactiver l'ensemble du pruning.

Comment définir par workflow ce qui est réellement enregistré ?

Avant même que le pruning n'entre en jeu, le paramètre du workflow détermine si une execution est enregistrée. Dans l'éditeur de workflow, vous ouvrez pour cela l'élément Settings via le menu à trois points en haut à droite, et vous définissez séparément si les executions échouées, réussies et manuelles doivent être enregistrées. De plus, l'option Save execution progress contrôle si n8n sauvegarde l'état de chaque nœud pendant l'exécution, ce qui, selon la documentation, peut augmenter la latence mais permet en contrepartie un redémarrage au point d'échec. Pour les workflows productifs à volume élevé, il vaut la peine de vérifier précisément quelles executions sont réellement pertinentes à long terme avant de modifier les variables de pruning globales. Dans le cadre de l'automatisation n8n de NordFlux, cette configuration fait partie intégrante de la mise en place côté serveur, afin que la base de données d'un système auto-hébergé reste durablement performante et que la souveraineté des données reste chez le client.

Questions fréquentes sur n8n Execution Data Pruning

Que se passe-t-il si je désactive EXECUTIONS_DATA_PRUNE ?

Si la variable est définie sur false, n8n ne supprime plus automatiquement aucune execution, et la base de données continue de croître sans limite. Cela peut être utile pour de courtes phases de test ou de débogage, mais c'est risqué en fonctionnement continu, car le fichier de base de données finira par atteindre les limites de performance et d'espace disque. Pour les instances en production, il est recommandé de laisser le pruning activé et d'adapter plutôt EXECUTIONS_DATA_MAX_AGE ainsi que EXECUTIONS_DATA_PRUNE_MAX_COUNT à ses propres besoins.

À quelle vitesse les executions terminées disparaissent-elles réellement de la base de données une fois la limite de pruning atteinte ?

Cela dépend des intervalles configurés : par défaut, n8n vérifie les candidats au soft delete toutes les 60 minutes et exécute le hard delete définitif toutes les 15 minutes. De plus, le tampon de hard delete, d'une heure par défaut, garantit que les executions terminées très récemment ne disparaissent pas immédiatement. En pratique, selon la configuration, il faut donc jusqu'à quelques heures pour qu'une execution quitte réellement la base de données.

Puis-je protéger certaines executions importantes de la suppression automatique ?

Oui, les executions annotées, c'est-à-dire celles portant des tags ou une évaluation dans l'éditeur n8n, sont exclues du nettoyage automatique selon la documentation. Cela convient pour garder durablement traçables certains cas d'erreur notables ou des exécutions de référence, sans désactiver le pruning global. Pour la grande majorité des executions de routine, la suppression automatique reste néanmoins active.

Dois-je encore faire quelque chose manuellement avec SQLite après le pruning ?

Oui, car SQLite ne restitue pas automatiquement l'espace disque supprimé au système d'exploitation, mais continue à l'utiliser en interne pour de futures executions. Quiconque souhaite réellement réduire l'espace disque utilisé doit, selon la documentation n8n, soit définir DB_SQLITE_VACUUM_ON_STARTUP, soit exécuter occasionnellement la commande VACUUM manuellement. Avec PostgreSQL comme base de données, ce problème se pose généralement de manière moins marquée, car sa gestion du stockage fonctionne différemment.