Does n8n's Simple Memory persist after a restart?

No. Simple Memory (the Window Buffer node) stores chat history in the workflow's own process, so it's wiped whenever n8n restarts, redeploys, or the workflow is re-saved. It's meant for testing a single conversation, not for production. If two users hit the same workflow, they can even share context because the buffer isn't scoped per session by default. For anything a real user touches, you need a database-backed memory node — Postgres or Redis.

Should I use Postgres or Redis for n8n AI agent memory?

Use Postgres when you want durable, queryable history that lives indefinitely — support agents, CRM assistants, anything you may audit later. Use Redis when you want fast, ephemeral context that auto-expires on a TTL — high-volume chat where week-old history is noise. In practice most agencies already run Postgres for n8n itself, so the Postgres Chat Memory node is the lowest-friction path: one connection, no new service. Add Redis only when latency or auto-expiry actually matters.

Why is my n8n AI agent's token bill so high?

Almost always because the memory window is too large. Every stored turn — plus every intermediate tool call — gets replayed into the model on the next message, so a chatty agent with a 50-message window can send tens of thousands of tokens per reply. Cap the context window length to the last 8–15 exchanges, don't store raw tool output in memory, and summarize long threads instead of replaying them verbatim. That single setting is the difference between a $40 month and a $400 one.

How do I give an n8n AI agent memory across separate sessions per user?

Set a unique session key on the memory node — usually the customer's ID, phone number, or email — so each person gets their own isolated conversation thread in Postgres or Redis. Without a session key, everyone shares one global memory and contexts bleed together. With it, the agent recalls a returning customer's history while keeping strangers apart. This is the single most-missed step when agencies move an agent from demo to production.

Do I need a vector database for n8n AI agent memory?

Not for conversation memory. Chat memory (Postgres/Redis) handles 'what did we just say?' A vector store answers 'what do we know?' — your docs, past tickets, product data — via retrieval. They're different jobs. Start with chat memory so the agent holds a conversation, then add a Vector Store node as a tool when the agent needs to pull from a knowledge base it can't fit in the context window.

n8n AI Agent Memory: The 2026 Setup Guide

We shipped an n8n support agent for a client last quarter. It demoed perfectly — remembered the customer's name, referenced the earlier question, felt genuinely smart. Then n8n redeployed overnight, and the next morning the agent greeted a returning customer like a total stranger. Every conversation had evaporated.

The culprit was the default memory node, and it's the single most common mistake we see when an agency moves an AI agent from a demo to something real.

Here's the short version: n8n's Simple Memory stores chat history inside the workflow's own process, so it's wiped on every restart, redeploy, or save. For a production AI agent you need a database behind it — the Postgres Chat Memory or Redis Chat Memory node — plus a per-user session key and a capped context window. That's the whole game. Below is exactly how we set it up, and the two settings that quietly decide your token bill.

Why Simple Memory Isn't Real Memory

When you drop an AI Agent node into n8n, it comes with Simple Memory (the Window Buffer node) attached by default. It works, which is the problem — it works just well enough to fool you in testing.

Simple Memory keeps the conversation in RAM, tied to the running workflow. So the moment n8n restarts, redeploys, or you re-save the workflow, the history is gone. Worse, without a session key it isn't scoped per person, so two users hitting the same workflow can bleed into each other's context. Fine for a five-minute test. A liability the second a real customer touches it.

n8n's own documentation on memory is blunt about this: Simple Memory is for quick testing, and production deployments should connect Postgres or Redis. Take that at face value. We've never once left Simple Memory in a workflow a client actually depends on.

The Memory Nodes n8n Actually Gives You

n8n ships several memory sub-nodes for the AI Agent. In practice you'll only reach for three:

| Node | Where history lives | Survives restart? | Reach for it when… | |------|--------------------|-------------------|--------------------| | Simple Memory (Window Buffer) | Workflow process (RAM) | ❌ No | You're testing a single conversation, nothing more | | Postgres Chat Memory | Your Postgres database | ✅ Yes, indefinitely | You want durable, auditable history — support, CRM, ops | | Redis Chat Memory | Redis, with a TTL | ✅ Until it expires | You want fast, ephemeral context that auto-cleans |

There are others — MongoDB, Motorhead, Zep, Xata — but for most agency builds they're solving a problem you don't have yet. Postgres and Redis cover the vast majority of real workflows, and one of them is almost certainly already running in your stack.

Our default: Postgres Chat Memory. If you're self-hosting n8n, you're already running Postgres for n8n itself. Pointing the memory node at that same database means zero new infrastructure — one connection, done. We only add Redis when a workflow is high-volume and week-old history is genuinely noise, because Redis lets it expire on its own via TTL instead of piling up.

The Setup We Actually Ship

Here's the exact sequence for a production-grade memory setup. It takes about ten minutes once your database is reachable.

Start from the AI Agent node in Tools Agent mode and connect your chat model — Claude or GPT. This is the orchestrator everything else plugs into.
Delete the Simple Memory sub-node and connect a Postgres Chat Memory node instead, using your existing Postgres credentials. (Swap in Redis Chat Memory if you want ephemeral context.)
Set a per-user session key. This is the step everyone skips. Point the session key at something unique and stable per user — customer ID, phone number, email. Now each person gets an isolated thread instead of a shared global memory.
Cap the context window length. Limit it to the last 8–15 exchanges. More on why this is the most important setting in a second.
Add a Vector Store node as a tool only if the agent needs to pull from a knowledge base — docs, past tickets, product data. Conversation memory and knowledge retrieval are different jobs (more below).
Wrap it in error handling and test with two session keys at once. Confirm the contexts stay separate and survive a restart before you call it done.

That's it. No exotic services, no custom code. The whole thing rides on infrastructure you already run. If you want the broader pattern this fits into, we walk through it in the n8n workflows every agency needs.

The Session Key Is the Whole Point

Let me hammer this one, because it's the difference between "smart agent" and "creepy agent."

A memory node without a session key gives every user the same global conversation. User A asks about their invoice, User B logs in, and the agent references User A's invoice. We've watched this happen in a staging environment and it is not subtle.

A memory node with a session key — keyed to the user's ID — gives each person their own thread. A returning customer gets an agent that remembers them; a new one gets a clean slate. Same workflow, correct behavior. If you take one thing from this post, it's that the session key isn't optional the moment more than one human can reach the agent.

The One Setting That Decides Your Token Bill

Most "my n8n agent is expensive" complaints trace back to one thing: the memory window is too big.

Here's the mechanism. Every stored turn gets replayed into the model on the next message. So does every intermediate tool call, if you're not careful. An agent with a 50-message window isn't sending one message to the model — it's re-sending the entire conversation, every single time. On a chatty support thread that's tens of thousands of tokens per reply, and it compounds all day.

Three fixes, in order of impact:

Cap the context window to the last 8–15 exchanges. This is the big lever. A returning customer rarely needs turn 3 of a conversation from last Tuesday replayed verbatim.
Don't store raw tool output in memory. If your agent calls an API that returns a 4KB JSON blob, that blob does not belong in the replayed context. Keep the result, drop it from memory.
Summarize long threads instead of replaying them. For genuinely long-running relationships, periodically collapse old history into a short summary the agent carries forward.

We took one client's agent from roughly $400/month to under $50 by changing exactly one number — the window length — and trimming tool output from memory. Nothing else. This is also where good error handling and monitoring pays off: you can actually see the token creep before the invoice does.

Chat Memory vs. Vector Store — Don't Confuse Them

This trips up a lot of people, so let's be precise.

Chat memory (Postgres/Redis) answers "what did we just say?" — the running conversation.
A vector store answers "what do we know?" — your documents, past tickets, product catalog, retrieved on demand.

They are not interchangeable, and you don't swap one for the other. A well-built agent uses both: chat memory so it can hold a coherent conversation, and a vector store node — added as a tool — so it can pull in knowledge that would never fit in a context window. Start with chat memory. Add retrieval when the agent clearly needs to reference something it can't remember on its own. We go deeper on the orchestration side in AI agents for marketing agencies.

If you're piping content or structured data through the agent, the same principle applies to how you feed it — see our n8n + Claude content pipeline for how memory and retrieval split responsibilities in a real build.

The Short Version

Simple Memory is volatile — it dies on restart. Never leave it in a workflow a client depends on.
Postgres Chat Memory is the default for durable, auditable history; Redis for fast, auto-expiring context.
Always set a per-user session key — without it, everyone shares one memory and contexts bleed.
Cap the context window to 8–15 exchanges — it's the single biggest lever on your token bill.
Chat memory ≠ vector store. One holds the conversation; the other retrieves knowledge. Real agents use both.

For the full node-level reference, n8n's Postgres Chat Memory docs are the authoritative source.

Want Your Agent to Actually Remember?

Most AI agents that "feel dumb" aren't running a worse model — they just have no memory, or the wrong kind. Fixing it is usually a ten-minute change plus one setting most people never touch.

At Vixi we build and maintain production n8n agents with persistent, per-user memory, capped token costs, and retrieval where it belongs — the kind that survive a restart and don't blow up your bill. If your agent forgets everyone the moment it redeploys, get a free automation audit and we'll show you exactly what to change.