Quelle mémoire pour votre AI Agent n8n ? Simple, Postgres, Redis : le comparatif

La plupart des tutoriels sur la mémoire de l'AI Agent n8n présentent chaque node isolément, sans répondre à la vraie question : lequel choisir pour votre cas. n8n propose plusieurs sous-nodes de mémoire pour l'AI Agent : Simple Memory, Postgres Chat Memory, Redis Chat Memory, MongoDB Chat Memory et quelques options plus spécialisées. Tous font la même chose en apparence — réinjecter l'historique de conversation dans le prompt — mais divergent sur ce qui compte en production : persistance, compatibilité avec le mode queue, expiration, volume. Cet article est le tableau de décision ; pour la mise en place détaillée, nos guides sur la mémoire de conversation (Simple Memory vs Postgres Chat Memory) et la mémoire long terme (vector store) prennent le relais.

Ce qu'un sous-node de mémoire fait vraiment

Le node AI Agent ne retient rien entre deux exécutions : chaque appel au modèle part d'un contexte vide. Le sous-node branché sur l'entrée Memory stocke chaque échange quelque part (RAM, table SQL, clé Redis…) puis rejoue les N derniers échanges de la même session avant chaque nouvelle question. Deux paramètres gouvernent tout le reste :

• La Session Key : l'identifiant qui sépare les conversations entre elles — et qui décide si deux utilisateurs risquent de partager leur historique.
• La fenêtre de contexte (context window length) : le nombre d'échanges rejoués à chaque appel, facturés en tokens d'entrée.

Le lieu de stockage — le seul point qui différencie les sous-nodes — devient critique dès que l'instance redémarre ou que plusieurs workers se partagent les exécutions.

Le tableau de décision

Mémoire	Persistance	Mode queue / multi-workers	Expiration (TTL)	Infra à opérer	Pour qui
Simple Memory	Non (RAM du process)	Non fiable	Non	Aucune	Prototype, démo, test dans l'éditeur
Postgres Chat Memory	Oui (table SQL)	Oui	Non (purge SQL planifiée)	PostgreSQL — souvent déjà là	Le défaut en production
Redis Chat Memory	Oui (hors du process n8n)	Oui	Oui, TTL de session natif	Un Redis — déjà là en mode queue	Fort trafic, sessions éphémères
MongoDB Chat Memory	Oui (collection)	Oui	Via index TTL MongoDB	MongoDB	Équipes déjà sur Mongo
Zep, Xata…	Oui (service dédié)	Oui	Selon le service	Un service de plus	Besoins avancés (résumé, enrichissement)

Trois lectures rapides de ce tableau :

• Vous prototypez : Simple Memory, zéro configuration, et n'y pensez plus — jusqu'à la mise en production.
• Vous avez déjà un PostgreSQL (la base de n8n lui-même, ou un projet Supabase — voir notre guide pour connecter n8n à Supabase) : Postgres Chat Memory, sans hésiter.
• Vous tournez en mode queue avec Redis : le Redis est déjà dans votre stack ; Redis Chat Memory y ajoute la mémoire de chat avec un TTL de session natif.

Les critères qui départagent

Persistance : que se passe-t-il au redémarrage ?

Simple Memory vit dans la RAM du process n8n : redémarrage, mise à jour, crash — tout disparaît sans avertissement. Les quatre autres survivent. Un agent qui « oublie » une conversation entamée la veille n'a pas un problème de prompt, il a une mémoire volatile ; notre article sur la mémoire de conversation détaille la migration pas à pas vers Postgres Chat Memory.

Mode queue : la mémoire doit être partagée entre workers

En mode queue, chaque exécution peut atterrir sur un worker différent. Une mémoire en RAM n'est pas partagée : le message 1 est traité par le worker A qui mémorise, le message 2 par le worker B qui ne sait rien. Symptôme typique : un agent qui se souvient parfois, de façon apparemment aléatoire. Toute mémoire externe règle le problème : tous les workers lisent et écrivent au même endroit.

TTL et purge : qui fait le ménage ?

Redis expire nativement les sessions après une durée configurable ; MongoDB peut faire de même avec un index TTL. Postgres ne purge rien tout seul : prévoyez un Schedule Trigger avec un DELETE sur les conversations plus anciennes que votre durée de rétention. Un historique de chat contient presque toujours des données personnelles : la purge est une obligation, pas une option.

Volume, latence et coût

À fort trafic, Redis lit et écrit plus vite qu'une table SQL — le même arbitrage qui motive un cache sémantique Redis devant les appels IA. Mais le vrai poste de coût est la fenêtre de contexte : vingt échanges rejoués à chaque appel, sur des centaines de conversations par jour, pèsent bien plus que quelques millisecondes de lecture. Notre guide sur le suivi du coût des appels IA montre comment mesurer cet effet.

Self-hosted vs cloud

Sur n8n Cloud, pas de mode queue ni de Redis à opérer : Simple Memory tient plus longtemps pour un agent modeste, et Postgres Chat Memory reste la voie de persistance la plus simple. En self-hosted, vous choisissez toute la stack — et dès que vous passez en mode queue, la mémoire externe devient une exigence, plus un confort.

La Session Key, avant tout le reste

Quel que soit le store choisi, une Session Key mal conçue ruine tout. La règle : unique par conversation, stable d'un message à l'autre. Avec le Chat Trigger, l'ID de session fourni suffit ; sur un webhook custom, dérivez-la d'un identifiant propre à l'utilisateur ou au fil :

Session Key: {{ $json.body.userId }}-{{ $json.body.channel }}

Une clé fixe (« default ») mélange tous les utilisateurs dans un seul historique — fuite de contexte et incident de confidentialité. Une clé instable (timestamp, ID d'exécution) crée une session neuve à chaque message — autant ne pas avoir de mémoire. Les deux articles du cluster détaillent les bons candidats canal par canal (Telegram, Slack, widget web…).

Mémoire courte + mémoire longue : le duo gagnant

Aucun de ces sous-nodes ne donne à l'agent une mémoire entre les conversations : ils rejouent le fil d'une session. Pour qu'un assistant se souvienne, douze conversations plus tard, qu'un client préfère être contacté le matin, il faut une deuxième couche : des faits distillés, stockés dans un vector store et rappelés par similarité — l'architecture à deux étages détaillée dans notre guide sur la mémoire long terme d'un agent IA. Une revue de Zeyu Zhang, Xu Chen et leurs co-auteurs publiée en 2024, « A Survey on the Memory Mechanism of Large Language Model based Agents » (Google Scholar), dresse précisément cette taxonomie : la conception de la mémoire — quoi écrire, comment le rappeler, quand l'oublier — y est identifiée comme le composant clé des interactions longues, les approches efficaces combinant mémoire courte et stockage externe interrogé à la demande.

Les erreurs classiques

• Session Key partagée entre utilisateurs ou entre canaux : la fuite de contexte la plus fréquente, et la plus grave.
• Fenêtre de contexte trop large : chaque échange rejoué est facturé en tokens d'entrée à chaque appel. Commencez à 10-15 échanges et ajustez en mesurant.
• Simple Memory conservé en production « parce que ça marchait en test » : ça marchait sur une instance mono-process qui ne redémarrait pas.
• Mémoire utilisée comme base de connaissances : les documents vont dans un pipeline RAG, pas dans l'historique de chat.
• Aucune purge : un historique qui grossit indéfiniment est un problème RGPD avant d'être un problème de stockage.

Si votre agent se comporte mal malgré une mémoire bien choisie, voyez notre revue des erreurs du node AI Agent. Et si vous orchestrez plusieurs agents en pipeline, gardez une mémoire par agent et par session : un historique partagé entre rôles différents pollue les contextes.

En résumé

Simple Memory pour prototyper, Postgres Chat Memory comme défaut de production (surtout si un PostgreSQL ou un Supabase existe déjà), Redis Chat Memory quand le trafic monte ou que le TTL natif simplifie la vie, MongoDB si c'est déjà votre base maison. Dans tous les cas : une Session Key unique et stable, une fenêtre de contexte mesurée, une purge planifiée. Et pour un agent qui se souvienne vraiment de ses utilisateurs, ajoutez l'étage supérieur — la mémoire long terme en vector store — au-dessus de la mémoire de conversation choisie dans ce comparatif.