De combien de serveur n8n a-t-il besoin ? RAM, CPU et stockage selon la charge de workflow

La quantité de serveur dont n8n a besoin dépend moins du simple nombre d'utilisateurs que du nombre d'exécutions parallèles et de la quantité de données binaires qui transitent par les workflows. n8n lui-même a testé, dans son propre benchmark, une instance unique avec 4 Go de RAM (type ECS c5a.large, mode principal avec Postgres) et a atteint jusqu'à 220 exécutions de workflow par seconde, mais avec un workflow très simple composé d'un déclencheur webhook et d'un nœud Edit Fields. Pour la plupart des automatisations de PME avec des nœuds plus complexes, du traitement de fichiers ou des appels IA, il ne s'agit pas d'une valeur durable réaliste, mais d'une limite supérieure en conditions de laboratoire. À jour au : août 2026.

Une petite instance suffit-elle pour démarrer ?

Pour démarrer, une instance petite à moyenne suffit généralement, tant que les workflows ne fonctionnent pas en permanence en parallèle avec une forte charge binaire. Dans le test propre à n8n, une instance unique avec 4 Go de RAM est restée stable jusqu'à un certain niveau de charge, mais les temps de réponse ont augmenté nettement sous une charge plus élevée, atteignant au pic plus de 100 secondes, tandis que le traitement se poursuivait en arrière-plan. Cela montre qu'une petite instance finit par traiter la charge, mais plus dans un délai utile pour des réponses webhook synchrones. Les détails de la configuration du test sont fournis par la documentation de performance de n8n.

Quand SQLite devient-il un problème ?

SQLite devient un problème au plus tard lorsque vous souhaitez passer à l'échelle sur plusieurs processus n8n. Pour le Queue Mode avec plusieurs workers, SQLite n'est, selon n8n, pas prévu ; une base de données Postgres est requise à la place, accessible à la fois par l'instance principale et par toutes les instances worker. Quiconque prévoit de croître devrait donc planifier dès le départ avec Postgres plutôt qu'avec SQLite, même si une instance unique avec SQLite fonctionne dans un premier temps pour de petites configurations non critiques.

Quand le passage au Queue Mode en vaut-il la peine ?

Le Queue Mode en vaut la peine dès qu'une instance unique atteint ses limites, par exemple en raison de nombreux utilisateurs simultanés, de nombreuses exécutions parallèles ou de pics de charge sur les webhooks. En Queue Mode, une instance principale prend en charge les déclencheurs, les webhooks et l'interface, tandis que des instances worker séparées prennent en charge les exécutions proprement dites ; de plus, Redis est indispensable en tant que message broker. Par défaut, chaque worker traite jusqu'à 10 tâches simultanément, mais n8n recommande de limiter la concurrency par worker à au moins 5 afin de ne pas épuiser le pool de connexions à la base de données. La façon de configurer cela en détail est décrite dans la documentation n8n sur le Queue Mode.

Qu'est-ce qui change avec des données binaires volumineuses ?

Les données binaires telles que les PDF ou les images modifient le calcul bien plus fortement qu'un simple traitement JSON, car elles génèrent des besoins supplémentaires en mémoire et en E/S. En Queue Mode, le stockage des données binaires sur le système de fichiers local n'est, selon la documentation, pas pris en charge ; un stockage externe compatible S3 est recommandé à la place. Quiconque traite de nombreux documents devrait intégrer ce point dès le départ dans la planification du serveur, plutôt que de le remarquer seulement une fois le disque ou la mémoire vive pleins.

Comment dimensionner pour mon propre cas ?

La façon la plus fiable de dimensionner consiste à tester votre propre workflow réaliste plutôt que de se fier à des chiffres génériques. n8n souligne lui-même explicitement que la performance réelle dépend du type de workflow, des ressources disponibles et de la configuration, et recommande de réaliser ses propres benchmarks avec son framework de test maison. Pour une utilisation en production sur votre propre serveur hébergé en Allemagne ou dans l'UE, nous vous accompagnons chez NordFlux pour la mise en place de n8n y compris le choix du serveur et de la base de données adaptés.

Questions fréquentes sur le dimensionnement des serveurs n8n

Une petite instance cloud avec peu de RAM suffit-elle pour n8n ?

Pour des workflows simples et non parallèles, une petite instance peut suffire, comme le montre le propre test de n8n avec 4 Go de RAM. Cependant, dès que plusieurs workflows s'exécutent simultanément ou que des données binaires sont traitées, le besoin augmente nettement, c'est pourquoi un test réalisé dans des conditions de charge réalistes est plus pertinent qu'une recommandation générale.

Ai-je absolument besoin du Queue Mode ?

Non, pour des configurations plus petites avec une charge parallèle maîtrisée, une instance unique suffit. Selon n8n, le Queue Mode devient surtout pertinent lorsqu'une instance atteint ses limites de mise à l'échelle et que des workers supplémentaires doivent répartir la charge.

Combien d'exécutions par seconde n8n peut-il gérer au maximum ?

Dans son propre benchmark, n8n annonce lui-même jusqu'à 220 exécutions de workflow par seconde sur une instance unique, mesurées avec un workflow de test très simple. Pour des workflows plus complexes comportant davantage de nœuds, des appels API externes ou des données binaires, la valeur réaliste est, selon l'expérience, nettement plus basse.

n8n fonctionne-t-il avec SQLite en production ?

Pour une instance unique avec une charge maîtrisée, SQLite est en principe utilisable. Pour le Queue Mode avec plusieurs workers, SQLite n'est cependant, selon la documentation, pas prévu ; Postgres y est requis.