2026 n8n : migrer de SQLite à PostgreSQL, préserver les workflows ?

L’instance n8n démarre avec PostgreSQL, mais les anciens workflows et identifiants ne sont plus visibles.

Ce guide s’adresse aux personnes qui exploitent déjà n8n en auto-hébergement et hésitent sur les données à conserver avant de passer de SQLite à PostgreSQL.
Il est aussi destiné aux petites équipes qui doivent préserver utilisateurs, partages et accès aux identifiants.
Les responsables d’une mise à niveau n8n 2.x y trouveront une façon de dissocier les risques de migration de base et de changement de version.

Dernière vérification : 31 octobre 2026, à partir de la configuration des bases de données prise en charge par n8n, de sa documentation CLI et de ses documents de migration 2.0.

Migration n8n de SQLite vers PostgreSQL : le périmètre avant la procédure

SQLite est la base par défaut de n8n, tandis que PostgreSQL fait partie des bases configurables officiellement. Cela ne signifie pas qu’un changement de moteur transporte automatiquement l’ancienne base : la configuration indique à n8n où se connecter, mais ne constitue pas, à elle seule, une copie des données existantes. La documentation officielle sur les bases prises en charge distingue la configuration du moteur et les paramètres de connexion.

Avant de choisir une méthode, établissez une liste des éléments nécessaires au fonctionnement réel de l’instance :

• Flux de travail : définition, identifiant, état actif ou inactif et éventuels liens avec les utilisateurs ou projets.
• Identifiants : données chiffrées, associées à une clé de chiffrement. Un export de ces données n’est pas exploitable si la destination ne peut pas les déchiffrer.
• Comptes et relations d’équipe : utilisateurs, projets, partages et associations qui déterminent qui peut consulter ou exécuter un flux.
• Historique d’exécution : résultats passés, erreurs et données liées à l’exécution. Ne présumez pas qu’un export de flux les inclut.
• Données binaires : pièces jointes ou fichiers traités par les automatisations. Leur stockage dépend de la configuration ; vérifiez la documentation n8n sur le stockage binaire.

Cette séparation évite une erreur fréquente : considérer un export des workflows et des identifiants comme une migration complète de l’instance. La CLI documente l’import et l’export de ces objets, mais elle ne garantit pas, par cette seule fonction, la reprise de chaque relation d’équipe, de l’historique ou des données binaires. Consultez les commandes CLI d’import et d’export et vérifiez chaque catégorie selon la version installée.

Question : après un changement de base, les workflows et identifiants restent-ils disponibles ?
Ils le seront seulement si les données correspondantes ont été transférées ou importées dans la destination, et si la clé de chiffrement nécessaire aux identifiants est cohérente avec la méthode choisie. Un démarrage réussi sur PostgreSQL prouve que n8n peut accéder à cette base ; il ne prouve pas que les anciennes données y sont présentes.

Choix des personnes qui maintiennent l’instance

Les besoins diffèrent selon la responsabilité de la personne qui effectue la migration. Une base vide peut convenir à une instance de test ; elle ne convient pas automatiquement à une équipe qui dépend de partages et d’autorisations existants.

Question : faut-il conserver l’historique des exécutions ?
La réponse dépend des besoins de suivi, d’audit et de diagnostic, ainsi que des règles de conservation de l’équipe. L’historique constitue une catégorie distincte des workflows et des identifiants. La documentation n8n décrit les options de conservation et de purge des exécutions ; elles doivent être examinées séparément, plutôt que déduites de la procédure d’import des workflows. Consultez les règles officielles de conservation des données d’exécution. Si les anciens enregistrements sont indispensables, validez une méthode sur une copie avant toute intervention sur la base de production.

Pour une équipe, la vérification des partages ne se limite pas à constater que les workflows sont présents. La documentation n8n sur le partage des workflows aide à identifier les relations d’accès à vérifier dans la destination. Une migration qui conserve le contenu d’un flux, mais modifie sa visibilité ou l’accès à ses identifiants, peut interrompre une automatisation sans produire d’erreur immédiate au démarrage.

Vérifications séparées pour n8n 2.x

Ne combinez pas deux changements difficiles à diagnostiquer. Une migration de SQLite vers PostgreSQL et une montée de version peuvent chacune modifier le comportement attendu ; si elles sont exécutées simultanément, une anomalie de données ou d’exécution devient plus difficile à attribuer.

Pour un projet qui vise n8n 2.x, consultez le rapport officiel de migration vers la version 2.0 ainsi que les changements incompatibles de la version 2.0. Ces documents sont le point de départ pour déterminer ce qui s’applique au chemin entre la version effectivement utilisée et la version cible. Une expérience décrite dans un forum peut suggérer une piste, mais ne remplace pas les instructions officielles et ne démontre pas que la même méthode conviendra à une autre installation.

Question : que vérifier avant de mettre à niveau n8n 2.x ?
Relevez les versions de départ et d’arrivée, lisez les documents officiels correspondant à cette transition et effectuez les essais sur une copie représentative. Consignez séparément les résultats de la migration de base et ceux de la mise à niveau : si les workflows fonctionnent avant la mise à niveau, puis échouent ensuite, cette séparation aide à isoler la cause.

Procédure de préparation et de recette

La séquence suivante réduit le risque de confondre connexion à la nouvelle base et reprise complète de l’instance. Les commandes et variables exactes doivent être vérifiées dans la documentation correspondant à la version installée : elles ne sont pas interchangeables d’une méthode à l’autre.

• [ ] Figer l’état de départ. Notez la version de n8n, le moteur et la configuration active, le mode de stockage binaire, les règles de conservation de l’historique, ainsi que la clé de chiffrement utilisée. Inventoriez les flux actifs, les identifiants et les comptes concernés.
• [ ] Établir une sauvegarde récupérable. Conservez une copie de la base SQLite et des données associées à l’instance. Vérifiez que l’équipe sait où se trouve cette copie et comment la remettre en service. Une sauvegarde qui n’a jamais été restaurée ne démontre pas, à elle seule, qu’un retour arrière fonctionnera.
• [ ] Décider du contenu à reprendre. Distinguez les flux, les identifiants, les utilisateurs et partages, les historiques et les fichiers binaires. Pour chaque catégorie, indiquez la méthode envisagée, la source documentaire et le test qui permettra de confirmer le résultat.
• [ ] Préparer une destination isolée. Configurez PostgreSQL selon la documentation n8n et créez un environnement de test avec une copie représentative des données nécessaires. Vérifiez que la destination utilise les paramètres et la clé de chiffrement prévus, sans exposer les secrets dans un dépôt ou un journal.
• [ ] Tester les exports et les imports documentés. La CLI officielle prend en charge l’import et l’export des workflows et des identifiants. Examinez les options, les identifiants des objets et les risques de remplacement avant de lancer une importation ; effectuez d’abord l’essai sur la copie.
• [ ] Vérifier les relations d’équipe. Connectez-vous avec les rôles concernés, comparez les flux visibles et contrôlez les droits d’utilisation des identifiants. Ne concluez pas que les partages sont préservés simplement parce que les flux apparaissent dans l’interface.
• [ ] Recetter les comportements utiles. Testez l’ouverture et l’activation des flux, les appels d’identifiants, les déclenchements planifiés et les Webhooks, ainsi que les enregistrements d’exécution attendus. Si les fichiers binaires sont nécessaires, confirmez aussi leur disponibilité après migration.
• [ ] Définir le retour arrière avant la bascule. Fixez le signal qui impose l’arrêt de la migration, la personne qui prend cette décision et la procédure pour revenir à la sauvegarde. Ne supprimez ni ne modifiez la seule copie de SQLite tant que les contrôles ne sont pas concluants.

Ce plan constitue une recette, pas une procédure universelle de transfert de toutes les tables internes. Si les données exigées ne sont couvertes par aucun chemin officiellement documenté pour la version concernée, suspendez la bascule et cherchez une méthode testable avant d’intervenir sur l’instance de production.

Conditions de décision et comparaison des méthodes

Appliquez ces branches avant de choisir entre une nouvelle base vide et une reprise des données existantes :

• Si l’instance sert uniquement à des essais et que ses flux et identifiants peuvent être recréés, conservez une sauvegarde, puis évaluez une nouvelle instance PostgreSQL sans importer l’ancien historique.
• Si des flux ou identifiants doivent être conservés, utilisez les fonctions officielles d’import et d’export appropriées, puis vérifiez le chiffrement, les identifiants des objets et le fonctionnement réel de chaque automatisation.
• Si des comptes, projets ou partages sont essentiels, exigez un essai sur une copie et validez les accès par rôle ; si ces relations ne sont pas reprises par la voie confirmée, ne basculez pas en supposant qu’elles suivront les workflows.
• Si l’historique d’exécution est obligatoire, ne choisissez pas une méthode communautaire sans test de complétude et de restauration. Si aucune méthode adaptée n’est validée, différez la migration ou prévoyez explicitement de ne pas conserver ces enregistrements.
• Si la migration et la mise à niveau sont toutes deux prévues, séparez les fenêtres de recette et les critères de validation ; revenez à l’étape précédente dès qu’un contrôle critique échoue.

Le choix ne se résume donc pas à « SQLite contre PostgreSQL ». Il porte sur le coût opérationnel d’une reprise vérifiable, les données réellement utiles à l’équipe et la capacité à revenir à l’état initial. Une petite instance personnelle peut ne pas justifier la migration si SQLite répond à son usage et qu’aucune contrainte concrète ne la rend nécessaire. Pour une instance durable, le passage à PostgreSQL peut être pertinent, mais seulement si le périmètre de données et les contrôles sont définis avant l’intervention.

Stockage et environnement après migration

La migration ne crée pas automatiquement une sauvegarde, une haute disponibilité ni une stratégie de restauration. La base PostgreSQL, les fichiers binaires et les copies de secours doivent être considérés comme des éléments distincts du plan d’exploitation. Estimez les besoins à partir de la croissance observée, de la politique de conservation des exécutions et de la taille des fichiers traités, plutôt qu’en supposant qu’un changement de moteur réduira ou stabilisera l’espace nécessaire.

Si la charge s’exécute sur une machine partagée ou une petite instance virtuelle, la migration ne supprime pas les limites de ressources, les variations de performance liées à la cohabitation ou les contraintes de stockage. Une machine physique AMD dédiée peut être plus cohérente lorsque n8n et PostgreSQL doivent fonctionner durablement avec des ressources réservées ; elle ne remplace cependant ni une sauvegarde externe ni les contrôles de migration décrits ici. Pour comparer l’environnement et les systèmes disponibles, consultez la présentation des machines proposées par XFP Cloud. Les choix de période de facturation sont présentés dans les modalités de facturation.

Avant de décider, vérifiez aussi les exigences de confidentialité de vos flux et des données traitées ; la page consacrée à la gestion des données chez XFP Cloud peut compléter cette évaluation. Si un usage reste léger, temporaire ou facilement recréable, une instance existante peut être suffisante : le passage à une machine dédiée n’est pas une condition technique de la migration. En revanche, si l’objectif est d’exploiter durablement n8n et PostgreSQL sans partager les ressources de calcul avec d’autres locataires, comparez les capacités, le système et la période de facturation indiqués dans la fiche produit avant de choisir une machine dédiée AMD de XFP Cloud.