Which memory for your n8n AI Agent? Simple, Postgres, Redis: the comparison

Most tutorials about n8n AI Agent memory cover each node in isolation, without answering the actual question: which one to pick for your case. n8n ships several memory sub-nodes for the AI Agent: Simple Memory, Postgres Chat Memory, Redis Chat Memory, MongoDB Chat Memory and a few more specialized options. On the surface they all do the same thing — replay the conversation history into the prompt — but they diverge on what matters in production: persistence, queue-mode compatibility, expiry, volume. This article is the decision table; for detailed setup, our guides on conversation memory (Simple Memory vs Postgres Chat Memory) and long-term memory (vector store) take over from here.

What a memory sub-node actually does

The AI Agent node retains nothing between executions: every model call starts from an empty context. The sub-node plugged into the Memory input stores each exchange somewhere (RAM, SQL table, Redis key…) and replays the last N exchanges of the same session before each new question. Two parameters govern everything else:

• The Session Key: the identifier that keeps conversations apart — and that decides whether two users risk sharing a history.
• The context window length: how many exchanges are replayed on each call, with a direct impact on billed input tokens.

The storage location — the only thing that actually differs between sub-nodes — becomes critical the moment the instance restarts or several workers share the executions.

The decision table

Memory	Persistence	Queue mode / multi-worker	Expiry (TTL)	Infra to run	Best for
Simple Memory	No (process RAM)	Not reliable	No	None	Prototype, demo, editor testing
Postgres Chat Memory	Yes (SQL table)	Yes	No (scheduled SQL purge)	PostgreSQL — often already there	The production default
Redis Chat Memory	Yes (outside the n8n process)	Yes	Yes, native session TTL	A Redis — already there in queue mode	High traffic, ephemeral sessions
MongoDB Chat Memory	Yes (collection)	Yes	Via a MongoDB TTL index	MongoDB	Teams already on Mongo
Zep, Xata…	Yes (dedicated service)	Yes	Depends on the service	One more service	Advanced needs (summarization, enrichment)

Three quick reads of this table:

• You are prototyping: Simple Memory, zero configuration, and forget about it — until production.
• You already run PostgreSQL (n8n's own database, or a Supabase project — see our guide on connecting n8n to Supabase): Postgres Chat Memory, no hesitation.
• You run in queue mode with Redis: the Redis is already in your stack; Redis Chat Memory adds chat memory with a native session TTL — conversations expire on their own.

The criteria that settle it

Persistence: what happens on restart?

Simple Memory lives in the RAM of the n8n process: a restart, an update, a crash — everything vanishes with no error and no warning. The other four survive. An agent that "forgets" a conversation started the day before doesn't have a prompt problem, it has volatile memory; our conversation memory article walks through the loss scenarios and the step-by-step migration to Postgres Chat Memory.

Queue mode: memory must be shared across workers

In queue mode, each execution can land on a different worker. RAM-based memory is not shared: message 1 is handled by worker A, which remembers; message 2 by worker B, which knows nothing. The typical symptom: an agent that remembers sometimes, seemingly at random — and the bug disappears when you test on a single-process instance. Any external memory solves it: all workers read and write in the same place.

TTL and purge: who cleans up?

Redis expires sessions natively after a configurable duration; MongoDB can do the same with a TTL index. Postgres purges nothing by itself: plan a Schedule Trigger running a DELETE on conversations older than your retention period. A chat history almost always contains personal data: purging is a retention obligation, not a storage option.

Volume, latency and cost

At high traffic, Redis reads and writes faster than a SQL table — the same trade-off that motivates a semantic Redis cache in front of AI calls. But the real cost driver is the context window: twenty exchanges replayed on every call, across hundreds of conversations per day, weigh far more than a few milliseconds of read time. Our guide on tracking AI call costs shows how to measure that effect.

Self-hosted vs cloud

On n8n Cloud there is no queue mode and no Redis to operate: Simple Memory holds up longer for a modest agent, and Postgres Chat Memory remains the simplest persistence path. Self-hosted, you choose the whole stack — and once you move to queue mode, external memory stops being a comfort and becomes a requirement.

The Session Key comes before everything else

Whatever store you pick, a badly designed Session Key ruins it all. The rule: unique per conversation, stable from one message to the next. With the Chat Trigger, the provided session ID is enough; on a custom webhook, derive it from an identifier that genuinely belongs to the user or the thread:

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

A fixed key ("default") merges every user into a single history — a context leak and a privacy incident. An unstable key (timestamp, execution ID) creates a fresh session on every message — you might as well have no memory at all. Both cluster articles detail the right candidates channel by channel (Telegram, WhatsApp, Slack, web widget).

Short-term + long-term memory: the winning pair

None of the sub-nodes in this comparison gives the agent memory across conversations: they replay a session's thread, nothing more. For an assistant to remember, twelve conversations later, that a customer prefers to be contacted in the morning, you need a second layer: distilled facts, stored in a vector store and recalled by similarity — the two-tier architecture detailed in our guide on long-term memory for an AI agent. A survey by Zeyu Zhang, Xu Chen and co-authors published in 2024, "A Survey on the Memory Mechanism of Large Language Model based Agents" (Google Scholar), maps out exactly this taxonomy: memory design — what to write, how to recall it, when to forget it — is identified as the key component that lets an LLM agent sustain long interactions, with the effective approaches combining a short interaction memory and external storage queried on demand. This article's comparison covers the first tier; the vector store is the second.

The classic mistakes

• A Session Key shared between users or channels: the most frequent context leak, and the most serious one.
• A context window left too wide: every replayed exchange is billed as input tokens on every call. Start at 10-15 exchanges and adjust while measuring.
• Simple Memory kept in production "because it worked in testing": it worked on a single-process instance that never restarted.
• Memory used as a knowledge base: documents belong in a RAG pipeline, not in the chat history.
• No purge at all: a history that grows forever is a GDPR problem before it is a storage problem.

If your agent misbehaves despite a well-chosen memory, the diagnosis often runs through other suspects — see our review of AI Agent node errors. And if you orchestrate several agents in a pipeline, keep one memory per agent and per session: a history shared between agents with different roles pollutes both contexts.

Key takeaways

Simple Memory to prototype, Postgres Chat Memory as the production default (especially if a PostgreSQL or Supabase already exists), Redis Chat Memory when traffic climbs or the native TTL simplifies your life, MongoDB if that's already your house database. In every case: a unique and stable Session Key, a measured context window, a scheduled purge. And for an agent that truly remembers its users, add the upper tier — long-term memory in a vector store — on top of the conversation memory you picked from this comparison.