n8n AI Agent Memory: The Three Shapes That Work (And One That Doesn't)

n8n's AI Agent node ships with a memory slot you can plug something into. What you plug in decides whether your agent actually remembers anything useful or just performs a passable impression of remembering. After watching a lot of n8n agent setups fall apart in the same three ways, here's the shape-by-shape decision map.

The TL;DR: the default Window Buffer Memory is fine for a 10-minute demo and dangerous for anything that runs longer. Postgres Chat Memory on Supabase is the workhorse for production. A graph-backed memory layer (we'll get to memnode in a minute, but the general pattern applies) is the right shape when your agent needs to learn rather than just remember.

Why memory matters more in n8n than in raw LLM SDKs

The n8n AI Agent node is a multi-step tool-using loop. Each execution can fire off several model calls, tool calls, retries, and conditional branches. Without persistent memory, every workflow run starts cold. The user types "schedule a meeting like the one I did yesterday" and the agent has no concept of yesterday.

Workflows that don't need memory exist: stateless one-shot tasks like "summarize this email" or "extract the address from this PDF." Most genuinely useful agentic workflows are stateful, though. A research agent that remembers what it already searched. A support agent that remembers the customer's last three tickets. A coding agent that remembers the repo conventions you taught it. All of them need a memory shape that survives between workflow runs.

n8n's design makes the choice explicit: the Memory connection is its own slot on the AI Agent node, alongside Chat Model and Tool. You pick what backs it. The four built-in options ship in the box; the interesting ones are the third-party connections.

Shape 1: Window Buffer Memory (the default, the trap)

Window Buffer Memory is the default option n8n suggests. It keeps the last N messages in process memory. When the workflow ends, the memory ends. The next run starts fresh.

This is fine for two narrow cases. Demos where you want to show the agent "remembering" something within a single chat session. Single-call workflows where the memory only needs to persist for the duration of one execution.

It is dangerous when you scale beyond those cases. Three failure modes show up consistently:

1. Memory dies on n8n restart. Process memory means exactly that. If your n8n container restarts (deployment, OOM, host reboot, scheduled cron), the buffer is gone. Every user in the middle of a conversation loses context.
2. No cross-user isolation. Window Buffer is a single buffer per workflow execution, not per user. If you have multiple users hitting the same workflow, you either build per-session routing yourself or every user ends up sharing one stream of memory.
3. Silent truncation. When the buffer fills, oldest messages drop off. The agent doesn't know they dropped off. Two days into a conversation, the agent has no memory of the first interactions. The user has no idea why.

Use Window Buffer Memory for prototyping. Replace it before production.

Shape 2: Postgres Chat Memory on Supabase (the workhorse)

This is what most production n8n agents end up running. Postgres Chat Memory persists conversation history to a Postgres database. Supabase happens to be the easiest Postgres provider to wire up from n8n; the actual database could be anything.

The setup is straightforward:

1. Create a Supabase project. The free tier has enough headroom for development and small production loads.
2. Copy the connection string from the Supabase dashboard (Project Settings → Database → Connection string).
3. In n8n, add a Postgres Chat Memory node to your AI Agent workflow.
4. Create a new Postgres credential. Paste the host, database name, user, password, and port from Supabase. Most setups need SSL enabled.
5. Set the session ID expression to something stable per user, e.g. {{ $('Webhook').item.json.headers.x_user_id }} or whatever your auth layer hands you.
6. Run the workflow once. n8n auto-creates the required table with an auto-incrementing primary key, session_id column, and a JSONB column for message content.

What you get: durable conversation history per user, queryable by session id, that survives n8n restarts and scales horizontally as your workflow does. The Postgres side is doing real work; n8n is just orchestrating reads and writes.

Three things to watch for:

• JSONB column growth. Each message is appended; nothing prunes. A long-running conversation accumulates messages indefinitely. Add a periodic cleanup workflow or use a Postgres TTL pattern to drop old messages.
• Token budget on recall. The Postgres Chat Memory node loads the full session history on every call. Long sessions = large prompts = expensive model calls and slow responses. Either cap the lookback (n8n exposes this on the node) or post-process the history into summaries before stuffing it into the model.
• Session ID collisions. If your session id derivation has a bug (using a request id instead of a user id, for instance), users start sharing memory streams in subtle ways. Always test with two users in parallel before shipping.

Shape 3: graph-backed memory (when conversation isn't enough)

Postgres Chat Memory is great at remembering what was said. It's bad at remembering what was learned. The difference matters once your agent's job is anything more than "carry context across turns."

Concrete example. A research agent runs once a day, searches the web for new info on a topic, and reports back. With Postgres Chat Memory, the agent remembers that it searched. It does not remember what it found in a structured way. Tomorrow's run has no idea what yesterday's run learned. The agent re-searches the same things and re-reports the same conclusions.

What's needed is memory that stores facts, not message logs. A graph-backed memory layer can do this. The agent writes typed facts ("X is a competitor of Y", "the user mentioned they prefer flat-rate pricing", "the topic page on Z was last updated 2026-05-14"). The graph dedupes, links, and serves them back as inspectable structures.

This is what we built memnode for, and it's the shape we'd recommend over Postgres Chat Memory for these specific patterns:

• Research / discovery agents that need to remember what they've already found, not just what they've said.
• Long-running multi-session agents where individual messages aren't the unit of memory; specific facts are.
• Agents that learn user preferences across many sessions and need to recall a specific preference without re-loading every prior conversation.
• Agents that need correctability. "The user actually prefers Y, not X, please update your memory" is a single graph update; in a chat-memory backend it's a confused mess.

The memnode integration with n8n works through a standard HTTP node: the agent calls a recall endpoint on session start, writes typed facts at session end, and reads/writes individual facts mid-session through additional tool calls. No proprietary n8n node required; the integration is just HTTP, which is the point.

The decision tree, in three lines

1. Prototype only? Window Buffer Memory.
2. Conversation needs to survive restarts and isolate per user? Postgres Chat Memory on Supabase.
3. Agent needs to learn facts, not just remember messages? Graph-backed memory (memnode or equivalent).

What about the other built-in memory nodes?

n8n ships several other options. Quick verdicts:

• Redis Chat Memory. Fast, good for short-lived session context, expensive at scale. Pair with Postgres for long-term, use Redis for in-flight. Don't use it as the only memory backend; the eviction policy will surprise you.
• Zep Memory. Hosted memory service, similar shape to graph-backed but commercial. Real option if you want managed and don't want to run anything yourself. Watch the per-message pricing and the cloud-trust trade-off.
• Motorhead. Less common, open source. Works but maintenance has been thin; not recommended for new deployments.

Cost shape, end-to-end

What this actually costs to run, by shape:

• Window Buffer: Free. Memory lives in your n8n container.
• Postgres on Supabase free tier: Free until you exceed 500MB of database storage. For most n8n agent workloads, this lasts months. After that, Supabase's paid tiers start at $25/month.
• Self-hosted Postgres: Whatever your existing Postgres costs. If you already run one, marginal cost is near zero.
• Redis: A small Redis instance ($5-15/month from any provider) is plenty for chat-memory workloads.
• Memnode (local): Free, single binary, lives on the n8n host.
• Memnode (hosted) or Zep: Per-memory pricing; depends on your write/read volume.

For most teams starting out, Postgres Chat Memory on Supabase is the right default. The free tier covers development indefinitely and the migration to a real backend later is straightforward because the data model is just a Postgres table.

One thing to avoid

Do not use the n8n internal data store ("static data" / workflow execution data) as a memory backend. It's not what it's for. It's a key-value store scoped to workflow executions and it has size limits that bite at production scale. Several blog posts suggest this as a "free memory hack" and it ends in confusion when the data quietly disappears or workflows fail with size errors.

The shape memnode optimizes for

If you've gotten this far and you're curious, the differences that matter when picking memnode specifically over Postgres Chat Memory or Zep:

• Local-first by default. The data plane runs on your machine or your VPS. Conversation histories with sensitive content (customer support, internal docs, personal life) don't leave your infrastructure.
• Lineage as a primitive. Every fact the agent stored has a provenance chain. When the agent recalls something wrong, you can audit why and correct the source.
• Namespace scoping. One memnode instance can hold separate memory spaces for different agents, customers, or projects, without cross-talk.
• HTTP-shaped integration. No n8n-specific node required. Standard HTTP Request nodes work, which means the integration survives n8n upgrades and doesn't depend on a maintained third-party node package.

For most n8n agents in 2026, the right answer is still Postgres Chat Memory on Supabase. It's free, it's well-understood, and it solves the most common shape. Reach for memnode (or another graph-backed memory layer) when "remember what was said" stops being the right shape for what your agent needs to do.

Related

• Mem0 Plugin for AI Editors vs Memnode
• Agent Memory Benchmarks 2026: The Real Numbers
• Vector embeddings are the wrong default for agent memory
• Hosted vs Local Agent Memory: When Each Fits