Large files in n8n: memory, binary data, and OOM crashes

A workflow that downloads a two-page PDF or a small image runs fine no matter n8n's default settings. The day that same workflow receives a 2GB video, a batch of high-resolution scans, or a CSV export with hundreds of thousands of rows, the instance can slow down and then crash with a memory error — often without a very explicit message. This guide explains how n8n actually handles binary data internally, which limits to configure, and how to design a workflow that absorbs large files without bringing the server to its knees.

How n8n stores binary data internally

Every time a node handles a file — an HTTP download, an email attachment, a Google Drive export, an upload through a form — n8n wraps that content in a binary object attached to the item flowing between nodes. How that content is physically stored during execution depends on the mode set via the N8N_DEFAULT_BINARY_DATA_MODE environment variable:

• default (memory) — the default setting. Binary content is kept in RAM for the entire execution. Fastest, but also the most fragile: every large file, multiplied across concurrent executions, adds directly to the process's memory footprint.
• filesystem — binary files are written to the instance's disk instead of being kept in RAM, and only a reference travels between nodes. Much more memory-efficient for large content, at the cost of slightly slower disk access.
• s3 — binary data is offloaded to an S3 (or S3-compatible) bucket. Restricted to Enterprise licenses, this mode is designed for queue mode and multi-worker setups, where shared storage accessible by every instance becomes necessary.
• database — content is stored in n8n's own database. Handy for quick troubleshooting, but poorly suited to genuinely large volumes: the database grows fast and read/write performance suffers.

Filesystem mode is not officially supported in queue mode without a shared network volume between workers (read-write EFS, for instance): since each worker has its own local disk, a file written by one wouldn't be visible to another. That's one of the reasons our guide to queue mode and Redis recommends checking this point before scaling a pipeline that handles a lot of binary data.

Size limits worth knowing

Two environment variables cap the size of files a self-hosted instance accepts, with deliberately conservative defaults:

Variable	Default	What it limits
N8N_PAYLOAD_SIZE_MAX	16MB	Maximum size of a JSON payload received (a standard webhook, an API response)
N8N_FORMDATA_FILE_SIZE_MAX	200MiB	Maximum size of a file sent as multipart/form-data (upload via a Form Trigger or a file-type webhook)

Both can be raised without a complex redeployment, simply by adding the variable to your docker-compose.yml or service configuration. n8n Cloud applies its own limits, generally more generous, without users having control over them. Raising these caps only solves part of the problem, though: beyond the size accepted on input, it's the RAM actually available on the server that determines whether the workflow holds up under load — see our guide to the real cost of self-hosted n8n to size a VPS accordingly.

Best practices for handling large files without crashing the instance

Filter before downloading. The most cost-effective habit: only fetch what the pipeline can actually process. A node that lists Google Drive files before downloading them should filter by MIME type and size at that very step, as recommended in our Google Drive automation guide — better to skip a 2GB video than to load it into memory just to reject it afterward.

Switch to filesystem mode as soon as binary content routinely exceeds a few dozen MB. The memory gain is immediate, and the latency impact stays marginal for most automation workflows (as opposed to a critical real-time use case). This is the setting to flip first, before even bumping the server's RAM.

Avoid carrying the full binary payload through the entire workflow. When only a piece of metadata is needed downstream (name, size, hash), extract it early and leave the binary behind rather than dragging it from node to node all the way to the end. A Code node placed right after the download can keep only what's actually needed for the rest of the flow.

Process in batches rather than as a single block. For processing a list of files (scans to OCR, invoices to extract), the Loop Over Items pattern avoids holding every file in memory at once — the load stays bounded to the batch size, regardless of the total volume to process. The same principle protects against 429 errors when calling an AI API on each file, as detailed in our rate limits guide.

Stream to the final destination rather than loading everything then sending it all back out. For a download-to-cloud-storage pipeline, it's better for the destination node to consume the binary stream directly rather than adding an unnecessary intermediate accumulation step. This matters especially for meeting transcription workflows, where source audio or video files can easily exceed several hundred MB.

Filesystem, S3, or database: which to choose

Situation	Recommendation
Single instance, occasional files < 50MB	Memory mode (default) is enough
Single instance, regular files > 50MB (scans, videos, exports)	Filesystem mode
Queue mode with multiple workers, Enterprise license available	S3 mode
Queue mode, no Enterprise license, genuinely large binary payloads	Redesign the workflow to limit binary data carried between nodes, or use a shared network volume in filesystem mode
One-off troubleshooting, very low volumes	Database mode, temporarily only

In a pipeline close to the one in the RAG Assistant Pack ($119), which ingests PDFs into a Supabase vector store, filesystem mode keeps a batch of scanned contracts, each several dozen MB, from saturating the instance's memory during text extraction and chunking. The same reasoning applies to an audit pipeline archiving large supporting documents, as in the Compliance & Audit Pack ($149): the audit trail itself needs to stay lightweight, while source documents are processed in batches and never all sit in memory at once.

A question older than n8n

The choice between storing a large object in a database or on a filesystem isn't specific to n8n — it's a classic systems design question. A landmark Microsoft Research study, To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem? (Sears, van Ingen & Gray, 2006 — see it on Google Scholar), measured this trade-off at scale and found that below roughly 256KB, storing the object in the database remains faster, while above roughly 1MB, the filesystem wins clearly — with the gap widening further as size increases. The exact threshold depends on the hardware and has shifted a lot since 2006, but the underlying principle still holds: n8n's filesystem and s3 modes exist precisely because past a certain size, having the instance's database (or its RAM) carry the binary payload becomes the wrong architectural choice, not just a configuration detail.

Going further

A workflow that handles large files deserves the same discipline as any critical pipeline: an Error Workflow that cleanly catches a failed download, a retry-with-backoff policy instead of failing outright, and memory monitoring on the instance as described in our n8n monitoring guide. Combined with a binary storage mode matched to the actual volume handled, these settings turn a classic point of fragility into an automation pipeline that holds up over time.