Flowise Memory Nodes: The Decision Map (Buffer Window, Redis, Zep, and the Agentflow Trap)

Flowise gives you more memory nodes than any other no-code agent builder, which is exactly the problem. Buffer Memory, Buffer Window Memory, two flavors of summary memory, Redis twice, DynamoDB, MongoDB Atlas, Zep. Ten options, one slot, and the docs describe each node without telling you which one your agent actually needs. After watching Flowise agents fail in the same handful of ways, here is the decision map.

The TL;DR: Buffer Window Memory is the right default for chatflows and it is already persistent (more on that surprise below). Redis-Backed Chat Memory is the production answer when you run multiple Flowise instances or care about TTLs. Zep or a graph-backed memory layer is the move when your agent needs to learn facts rather than reread transcripts. And the single most common Flowise memory bug is not a node choice at all, it is using chatflow memory nodes inside an Agentflow, where they silently do not work.

The trap to clear first: chatflow memory is not Agentflow memory

Flowise has two builder surfaces: classic chatflows and Agentflows (the multi-agent canvas). The memory nodes are not interchangeable. The standard memory nodes (Buffer Memory, Buffer Window Memory, the summary nodes, the database-backed chat memories) are chatflow nodes. Inside an Agentflow you must use the dedicated Agent Memory nodes, and the selection there is narrower, which is why the GitHub tracker has long-standing requests for Postgres and MySQL agent-memory backends.

The failure mode is quiet: you wire a Buffer Window Memory into an agent canvas, the flow runs, nothing errors, and the agent simply never remembers anything. If your Flowise agent has amnesia and you are sure you connected a memory node, this is the first thing to check.

What Buffer Window Memory actually does (it is better than it sounds)

The name suggests an in-process buffer that dies with the conversation, like n8n's Window Buffer Memory. Flowise's version is different in an important way: it stores messages in the chat_message table of Flowise's own database and fetches the last K interactions per session at runtime. The window is a read limit, not a storage limit.

Two practical consequences:

• It survives restarts. The history lives in whatever database backs your Flowise instance (SQLite by default, Postgres if you configured it). A redeploy does not wipe conversations.
• It is per-session by construction. The UI and embedded chat generate a unique chat ID per conversation automatically. For API callers, you scope conversations yourself by passing a session ID in the prediction request:

POST /api/v1/prediction/{chatflowId}
{
  "question": "What did we decide about the pricing tier?",
  "overrideConfig": { "sessionId": "user-42" }
}

Forgetting the sessionId override is the second most common Flowise memory bug: every API call lands in a fresh session and the agent greets every request like a stranger. If your agent remembers in the test UI but not via API, this is why.

When to reach for Redis

Redis-Backed Chat Memory (and its Upstash sibling) moves the message log out of Flowise's database into Redis. You want this in three situations:

• Multiple Flowise instances behind a load balancer. Memory in the local SQLite file means each instance has its own history. Redis gives all instances one shared log.
• You want conversations to expire. Redis TTLs handle "forget chats older than 30 days" for free; the chat_message table grows until you prune it.
• High-traffic embedded chat. The chat_message table is fine at hobby scale; at thousands of concurrent sessions, Redis is the boring, correct answer.

DynamoDB and MongoDB Atlas chat memory are the same idea with a different backend; pick whichever your team already operates. A small managed Redis ($5-15/month) is plenty for chat-memory workloads.

Summary memories: for long conversations, not long-term memory

Conversation Summary Memory and Conversation Summary Buffer Memory compress old turns through the LLM so the context window does not overflow on marathon chats. They are token-budget tools. Two things to know before choosing them:

• Every summarization pass is an extra LLM call, so they add latency and cost per turn.
• Summarization is lossy in an unaccountable way: the detail your user asks about next week is precisely the one the summary dropped. Compaction is not memory, the same argument we made for context-window compaction, applies node-for-node here.

Zep and the graph-backed shape

Everything above is a message log: the agent rereads transcripts. Zep Memory (cloud or self-hosted) is the first option in the Flowise list that extracts and stores facts. That is a different shape, the agent can know "the user's deploy target is Hetzner" without rereading the conversation where it came up. If your Flowise agent serves returning users across weeks, a fact-extracting layer beats a longer message window. The trade-offs between hosted services like Zep and a local-first engine are the subject of our hosted vs local comparison.

Clearing memory, and the support questions that follow

Three operational questions arrive within a week of shipping a Flowise agent with memory, so here are the answers up front:

• "How do I reset a conversation?" Per session: clear it from the chatflow's message history in the UI, or start a new sessionId for the user, the cheap, idiomatic move. Wiping the whole chat_message table resets every user at once; that is a database operation, not a button, and it should worry you exactly as much as that sentence implies.
• "Why does the embedded widget remember but my API client doesn't?" The widget manages its chatId in the visitor's browser storage. Your API client manages nothing unless you send the sessionId yourself. Same engine, different bookkeeping.
• "Does memory follow the user across chatflows?" No. Sessions are scoped to a chatflow. Two flows serving the same person have two histories, which is the right default and occasionally a surprise. Knowledge that should span flows belongs in a store outside Flowise, a vector store the flows share, or a memory service addressed over HTTP.

What each option costs

• Buffer Window Memory: free; rides the Flowise database you already run. Watch chat_message growth at scale.
• Redis / Upstash: $5-15/month managed covers chat-memory workloads comfortably; Upstash's per-request tier rounds to zero at hobby volume.
• DynamoDB / Mongo Atlas: effectively free at chat volumes if you already operate them; not worth adopting fresh just for chat logs.
• Summary memories: the backend is cheap, the extra LLM call per turn is the cost. A long-running summary chat can double the model spend of the flow it serves.
• Zep: hosted pricing scales with usage; self-hosted is your infrastructure plus your time. Fact-extraction passes are LLM calls too, budget them.
• Memnode (local): free, single binary next to your Flowise instance.

The decision map

• Demo or internal tool, single instance: Buffer Window Memory. It persists, it scopes per session, it is zero extra infrastructure.
• Production chat with multiple instances or TTL needs: Redis-Backed Chat Memory.
• Marathon single conversations that blow the context window: add Conversation Summary Buffer Memory, and accept the cost per turn.
• Returning users the agent should know things about: Zep or a graph-backed memory layer behind an HTTP node.
• Agentflow canvas: Agent Memory nodes only, full stop.

Migrating between memory nodes

Teams usually start on Buffer Window and outgrow it, so it is worth knowing what a migration actually moves. The honest answer: usually nothing. Each memory node owns its storage, the chat_message table for the built-in, your Redis keyspace for Redis-backed, Zep's store for Zep, and Flowise does not ship a migration path between them. Swapping the node means existing conversations effectively restart, which is fine for short-lived chat (users rarely notice losing week-old transcripts) and painful if you waited until the history was valuable. Two mitigations: do the backend switch early, while history is disposable, and keep anything that must survive a node swap, user preferences, learned facts, account context, outside the conversation log entirely, in a store the flow reads at session start. Transcripts are cattle; facts are pets. The node choice above only ever governed the cattle.

The shape memnode optimizes for

Flowise has no memnode node, and it does not need one: a memnode instance speaks HTTP, so a Custom Tool or HTTP node can write facts at the end of a flow and recall them at the start, the same integration shape we recommend for n8n. What that buys over the message-log nodes: lineage on every stored fact (when recall goes wrong you can see why), namespace scoping per customer or per flow, and local-first deployment, the conversation data stays on your infrastructure, which matters for exactly the internal-tooling use cases Flowise is most popular for.

For most Flowise builders the honest default remains Buffer Window Memory plus a sessionId you actually set. Reach for the fact-extracting shape when your agent needs to learn, not just remember.

Related

• n8n AI Agent Memory: The Three Shapes That Work
• CrewAI Memory: Four Stores Behind One Flag
• OpenAI Agents SDK Sessions: Persistent, Until You Need Actual Memory
• Hosted vs Local Agent Memory: When Each Fits