We have a workflow on n8n cloud that was working fine until we updated to the latest version. After the update, we started getting “n8n may have run out of memory while running this execution” errors. The workflow calls AI models multiple times in sequence to generate learning content. We tried splitting it into smaller sub-workflows and processing one item at a time, but we are still getting the same memory error. This workflow was running perfectly on the previous version without any changes on our end. Can you help us understand what changed with memory limits in this version and what we can do to fix it?
@Prateek_Bhardwaj which version did you go from and to? that determines whats actually changed. the reason splitting didnt help though, n8n keeps every items data in memory for the whole run, so if the AI outputs are still carried downstream or the sub-workflows hand their data back to the parent, it piles up regardless of batching. are you passing the model outputs forward, or writing them out and dropping them from the flow?
This sounds like a data-lifetime problem, not just a batch-size problem.
If every AI output stays attached to the item, splitting into sub-workflows may still carry the same growing payload downstream, or hand the payload back to the parent run. The pattern I would test is: write each model output somewhere durable, pass only an id/status to the next step, and drop the large fields before continuing.
The first cases I would check are:
- parent workflow receives all child outputs back
- each item carries previous model responses into the next AI call
- a failed run has to replay from the first AI call
- retry creates duplicate generated content because there is no stable content id/status
If each step reads by id and writes a status, memory stops depending on the full history of the run.
A few things changed in recent n8n versions that affect memory usage for AI-heavy workflows:
1. AI node output is now stored in execution data by default
In newer versions, the full output of each AI node (including the entire message history) is saved to the execution record. If you have multiple AI calls in sequence, each one accumulates the prior context and all of it ends up in the execution payload in memory simultaneously. On longer chains this can be 10-50x the memory footprint of older versions.
Practical fixes to try in order:
A. Split into sub-workflows with execution data pruning
Rather than calling AI nodes sequentially in one workflow, break each AI step into its own sub-workflow triggered via the Execute Workflow node. Each sub-workflow execution gets its own memory scope and is released when it finishes. Pass only the specific fields you need between them, not the full item.
B. Add a Set node after each AI call
Extract only the fields you actually need (e.g. just the generated text string, not the entire message array). This prevents the full AI output from being carried forward into the next node memory context.
C. Check your AI node Memory setting
If you are using an AI Agent node with a Memory sub-node (Buffer Memory, Zep, etc.) check the contextWindowLength or session size. In newer versions the default window size was increased, which means more tokens are held in memory per execution.
D. Contact n8n Cloud support
If the workflow was working on a previous version with identical logic, this may be a regression or a plan-level memory cap change. n8n Cloud support can see the execution logs and confirm whether it is a limit change or a memory growth issue in the workflow itself. Opening a support ticket alongside these fixes is worth doing.
It sounds like this could be related to a change in how memory is managed in the latest version rather than your workflow itself, especially since it was working before the update. Hopefully, the n8n team can confirm whether anything changed with memory limits or execution handling.
I concur here,
A. In large multi LLM call workflows separation of concerns helps in many ways and it would likely solve the memory issue you’re seeing.
build each LLM step as it’s own workflow and one main orchestrator, calling those agents as a tool call
B. You can also add one set node right after the trigger to structure downstream output, instead of multiple after each LLM call
Worth separating two different things here: the fixes above (sub-workflows, Set nodes, trimming the message history) will all genuinely help the memory footprint, but they’re really workarounds for a workflow that used to be correctly-sized and now isn’t, through no change on your end. Before doing surgery on the workflow itself, I’d nail down exactly what changed between your old and new version (changelog, not just “latest”) — if it’s a default behavior change (like the AI node now persisting full output to execution data, like pirateprentice mentioned), that’s worth flagging to n8n directly as a regression, since otherwise everyone upgrading hits the same wall with workflows that were previously fine.