SQLite ou PostgreSQL : quand le changement s'impose

Par défaut, n8n démarre avec SQLite, une base de données fichier sans processus serveur propre, qui ne nécessite pas d'installation séparée. Pour les instances de test, les automatisations individuelles et les débuts, cela suffit. Mais dès que vous exécutez plusieurs workflows simultanément, utilisez le mode file d'attente ou souhaitez exploiter plusieurs instances main, n8n recommande explicitement PostgreSQL à partir de la version 13 dans sa propre documentation. Le bon moment pour changer dépend moins d'un nombre fixe d'utilisateurs que de trois facteurs : le nombre d'exécutions simultanées, l'architecture prévue et la fréquence à laquelle des erreurs de verrouillage apparaissent déjà dans les journaux. État : juillet 2026.

Signes que SQLite atteint ses limites

Dans la communauté n8n, un même schéma d'erreur revient sans cesse : SQLITE_BUSY: database is locked. La cause réside dans la conception de SQLite, qui n'autorise qu'un seul accès en écriture par fichier à la fois. Si plusieurs workflows s'exécutent en parallèle ou si vous ouvrez l'éditeur pendant des exécutions actives, les accès en écriture sur le même fichier entrent en collision. À court terme, le mode WAL (Write-Ahead Logging) avec un délai d'attente (busy timeout) d'au moins 5000 millisecondes aide à réduire la fréquence des erreurs. La limitation sous-jacente à un seul rédacteur reste toutefois inchangée et revient de manière fiable en cas de charge croissante.

Les seuils que n8n indique lui-même

Dans sa documentation, n8n n'indique pas de nombre fixe d'exécutions par jour comme point de bascule, mais fait dépendre la limite de décisions d'architecture concrètes.

• Mode file d'attente prévu : Pour une exploitation en mode file d'attente en production, n8n indique directement que le mode d'exécution queue avec une base de données SQLite n'est pas recommandé. Dès que des processus worker écrivent en parallèle dans la même base de données, Postgres devient nécessaire.
• Plusieurs instances main (multi-main) : Pour la haute disponibilité avec plusieurs processus main, n8n exige explicitement une connexion à Postgres et Redis ; SQLite n'est pas prévu à cet effet.
• Concurrence des workers : La valeur de concurrence par worker est de 10 par défaut, n8n en recommande au moins 5. Avec de nombreux workers à faible concurrence, la documentation signale un risque d'épuisement des connexions à la base de données, une situation qu'une base de données à fichier unique sans véritable pool de connexions absorbe structurellement mal.
• Valeur de référence issue du benchmark : Dans les tests de performance officiels, une instance unique avec un backend Postgres atteint jusqu'à 220 exécutions de workflow par seconde. Ce n'est pas une limite de SQLite, mais cela montre la classe de charge pour laquelle Postgres est conçu dans n8n.
• Signal issu de n8n Cloud : Même dans son propre produit cloud, Postgres reste réservé aux offres Enterprise Scaling, tous les niveaux inférieurs fonctionnent sur SQLite. Cela reflète à peu près à partir de quand n8n juge lui-même le changement nécessaire.

Étapes de migration de SQLite vers PostgreSQL

Le changement se fait via export et import, et non via une conversion automatique du fichier de base de données.

• Préparer PostgreSQL : Fournir Postgres 13 ou plus récent, créer une base de données dédiée et un utilisateur dédié disposant de tous les droits sur celle-ci.
• Exporter les workflows et les credentials : Les sauvegarder via la CLI avec n8n export:workflow --all --output=backup/ et n8n export:credentials --all --decrypted --output=backup/. La sauvegarde déchiffrée des credentials doit ensuite être placée immédiatement dans un emplacement protégé et non accessible publiquement.
• Modifier les variables d'environnement : Définir DB_TYPE sur postgresdb et configurer l'hôte, le port, le nom de la base de données, l'utilisateur, le mot de passe et éventuellement le schéma via les variables DB_POSTGRESDB correspondantes.
• Démarrer n8n sur la base de données Postgres vide : n8n crée lui-même le schéma nécessaire au premier démarrage, il n'est pas nécessaire de créer les tables manuellement.
• Restaurer les données : Réimporter les états sauvegardés avec n8n import:workflow --separate --input=backup/ et n8n import:credentials --separate --input=backup/, puis tester les workflows par sondage.

Effort et limites du changement

Le passage n'est pas une opération en un clic, mais une petite fenêtre de maintenance : pendant l'export, la reconfiguration et l'import, n8n est brièvement à l'arrêt, et les historiques d'exécution détaillés ne sont pas automatiquement migrés par la voie standard. Pour les petites installations avec peu de workflows, l'effort reste limité ; pour les instances plus développées avec de nombreuses automatisations actives, il vaut la peine de tester au préalable sur une instance de staging. Celui qui ne souhaite pas assumer seul cette étape en cours d'exploitation peut aussi se faire accompagner en externe, par exemple dans le cadre d'un conseil n8n à prix fixe.

Questions fréquentes sur SQLite et PostgreSQL dans n8n

À partir de combien d'exécutions par jour dois-je passer à PostgreSQL ?

n8n ne donne pas de chiffre général. Selon la documentation, c'est plutôt l'architecture qui est déterminante : dès que le mode file d'attente ou plusieurs instances main sont prévus, Postgres s'impose comme condition préalable, indépendamment du volume d'exécution exact.

Puis-je simplement continuer à utiliser SQLite en augmentant seulement le busy timeout ?

Pour de petites instances peu parallèles, oui, cela peut réduire sensiblement les erreurs de verrouillage. Mais dès que vous évoluez vers le mode file d'attente ou le multi-main, cet ajustement ne suffit plus selon n8n.

Des données sont-elles perdues lors de la migration ?

La voie standard via export et import transfère de manière fiable les workflows et les credentials. Les historiques d'exécution complets n'y sont pas automatiquement inclus ; quiconque en a besoin devrait vérifier cela séparément avant la migration.

Ai-je obligatoirement besoin du mode file d'attente pour PostgreSQL ?

Non. Vous pouvez également utiliser PostgreSQL en mode single-main sans mode file d'attente, par exemple pour éviter les erreurs de verrouillage. Le mode file d'attente et le multi-main sont des niveaux d'extension distincts qui nécessitent en plus Redis.

Vous trouverez plus de détails sur le choix de la base de données et sur les variables d'environnement dans la documentation n8n sur le choix de la base de données ainsi que dans le guide sur le mode file d'attente.