Pourquoi la base de données n8n grossit à cause des executions et comment EXECUTIONS_DATA_PRUNE, la durée de conservation et les limites réduisent automatiquement le volume de données.
À 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
NordFlux construit des employés numériques pour les organisations : des automatisations et des agents KI qui prennent en charge le travail répétitif. Vous gardez le contrôle.
Pin Data, Mock Data et mode Debug dans n8n : comment tester des workflows avec des données de test fixées plutôt qu'en direct contre des systèmes de production.
Les données binaires en mémoire vive ou dans la base de données ralentissent n8n. Les modes filesystem et S3 résolvent le problème, avec les variables adéquates.
n8n facture par exécution de workflow, Zapier par étape d'action. Cette différence détermine quel plan convient réellement à votre automatisation.
EXECUTIONS_DATA_PRUNE et les durées de conservation associées déterminent la vitesse de croissance de votre base de données et ce qui reste traçable en cas de problème. NordFlux assure l'exploitation gérée de votre instance n8n, avec une configuration de pruning réfléchie pour chaque workflow. Lors d'un premier échange, nous examinons la taille actuelle de votre base et vos besoins de traçabilité.
