n8n Queue Mode Binary Data: Database or S3?

In n8n queue mode you cannot use filesystem binary data mode. n8n doesn't support it. Your supported options are database, which works on any self-hosted edition but stores every file as a row in Postgres with a 512 MiB per-file default cap, or external storage in s3 / azure, which requires a self-hosted Business or Enterprise license. Most agencies should run database mode with aggressive execution pruning, and only move to a bucket when the Postgres backup window starts to hurt.

That one sentence in the docs costs people a weekend. You do the responsible thing, you scale a self-hosted instance to queue mode with Redis and workers, you keep the filesystem setting you've been running happily for a year, and files start vanishing between the worker that created them and the UI that's trying to show them.

Here's what's actually going on, and how we size it before it becomes a 2am problem.

Why Filesystem Mode Stops Working the Moment You Enable Queue Mode

In regular mode, one n8n process does everything. It serves the editor, receives the webhook, runs the workflow, and writes the binary data to N8N_USER_FOLDER/binaryData on its own disk. Later, the same process reads it back. Everything lives in one place, so filesystem mode is perfect.

Queue mode breaks that assumption. The main process hands each execution to Redis, and a separate worker process — usually a separate container, often on a separate host — actually runs it. If that worker writes a 12 MB PDF to its local disk, that file exists on exactly one machine. The main process can't read it for the executions view. A second worker picking up a related job can't read it either. Restart that container on a host without a persistent volume and the file is simply gone.

So n8n doesn't leave it as a footgun. The docs are blunt: if you're using queue mode, switch to database, because filesystem mode isn't supported with queue mode.

There's a second thing worth knowing that catches people who think they don't process files at all. In queue mode, binary data storage also backs webhook responses that are too large to send through the queue. So even a workflow that only moves JSON can end up depending on your binary data configuration the day a client's API returns a fat payload.

The Default Nobody Changes Is the One That Crashes You

Before you get to the queue mode question, check what you're actually running. N8N_DEFAULT_BINARY_DATA_MODE defaults to default, and default means in memory.

That is fine for a few hundred KB of JSON. It is not fine the first time a client uploads a 40 MB scanned contract, and it is much less fine when three of those run concurrently. The instance doesn't degrade gracefully — the Node process runs out of heap and dies, taking every in-flight execution with it. If you've ever had an n8n container restart with no error in the workflow log, this is the first thing to check. It's the same family of problem as executions that get stuck in running forever: the symptom shows up in the UI, the cause is in the runtime.

Most people find this, set filesystem, and move on. That's the right call — right up until the day they enable queue mode.

The Four Modes, Compared Honestly

• default (in memory) — the shipping default. Zero configuration, fastest, and the source of most self-hosted OOM crashes. Use it only if your workflows genuinely never touch files.
• filesystem — writes to local disk at N8N_BINARY_DATA_STORAGE_PATH. Cheap, fast, unlimited by file size, and the correct answer for a single-process instance. Not supported in queue mode. Also needs a persistent volume, or a container restart eats your data.
• database — stores binary data in Postgres. Works on any self-hosted edition, survives restarts, and every process can read it regardless of which worker wrote it. Capped by N8N_BINARY_DATA_DATABASE_MAX_FILE_SIZE, which defaults to 512 MiB and cannot exceed 1024 MiB because that's the database column limit. Files above the cap fail to store.
• s3 / azure — external object storage, written as workflows/{workflowId}/executions/{executionId}/binary_data/{binaryFileId}. Scales effectively without limit, takes the load off your database, and requires a self-hosted Business or Enterprise license. It is not available on n8n Cloud, and n8n will refuse to start in s3 mode without a valid license key.

That last line is the part that decides most agency deployments. If you're on Community Edition and you've just moved to queue mode, database isn't one of three options — it's the only supported one you have.

How to Size This Before You Hit the Wall

The arithmetic is trivial and almost nobody does it. Take your average binary payload, multiply by executions per day, multiply by your retention window.

A document-processing workflow handling 4 MB PDFs, running 300 times a day, on n8n's default 14-day retention (EXECUTIONS_DATA_MAX_AGE is 336 hours) works out to roughly 16.8 GB of binary data sitting inside Postgres at steady state. That's before your actual application data, before indexes, before WAL.

Nothing breaks at 16.8 GB. What happens is quieter and more annoying: your nightly backup goes from 40 seconds to several minutes, your restore drill stops being a drill you can run casually, and autovacuum starts showing up in your monitoring. Then a client adds a second document workflow and the number triples.

Now run the same arithmetic with a 72-hour retention window: 3.6 GB. Same workflows, same volume, one environment variable. This is why pruning is the first lever, not the last.

Two Mistakes That Break S3 Binary Storage

If you do have the license and you're moving to a bucket, two specific things go wrong often enough to name.

The bucket region string

From n8n 2.6.4 onward, N8N_EXTERNAL_STORAGE_S3_BUCKET_REGION must contain only alphanumeric characters and hyphens. Underscores and other special characters fail validation, and n8n fails startup with connection errors even though the endpoint is reachable and the identical config worked on the previous version. Every signal points at networking. The cause is a string. If your provider doesn't require a region at all, set it to auto.

While you're there: upgrade main, worker and runner to the same version at the same time. Mixed versions produce protocol incompatibilities that look like storage failures.

The missing lifecycle rule

n8n delegates binary data pruning to S3. It does not delete objects from your bucket itself. If you don't set a bucket-level lifecycle configuration, your binary data is preserved indefinitely and your storage bill grows forever — which is exactly the cost problem you moved to S3 to avoid.

The inverse is also true and worth stating clearly, because it's the kind of thing that deletes production data. If you also enable S3 for execution data with N8N_EXECUTION_DATA_STORAGE_MODE=s3, do not add a lifecycle rule for it. n8n prunes execution data in S3 itself using the standard EXECUTIONS_DATA_* settings, and a lifecycle rule can delete objects n8n still references.

Binary data: you add the rule. Execution data: you don't. Same bucket, opposite answers.

Pruning Is Cheaper Than Any Storage Decision

Executions pruning deletes finished executions along with their execution data and their binary data, and it's enabled by default. The defaults are just generous. n8n prunes when either condition is met: the execution finished more than EXECUTIONS_DATA_MAX_AGE hours ago (default 336, so 14 days), or the total execution count exceeds EXECUTIONS_DATA_PRUNE_MAX_COUNT (default 10,000).

What we set on production instances:

• EXECUTIONS_DATA_MAX_AGE=72 — three days is enough to debug anything a client reports on Monday about Friday. Two weeks is hoarding.
• EXECUTIONS_DATA_SAVE_ON_SUCCESS=none on high-volume workflows that succeed reliably, with EXECUTIONS_DATA_SAVE_ON_ERROR=all kept on. You want the failures, not 9,000 identical successes.
• EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false — your test runs are not an audit trail.

Three gotchas worth holding onto:

• Executions in new, running or waiting status are never eligible for pruning. If you have workflows genuinely stuck, they and their binary data accumulate untouched no matter what your retention is set to.
• Annotated executions are never pruned. Tag or rate an execution and it's permanent. Handy for keeping a reference run, a slow leak if your team tags liberally.
• Binary data pruning operates on the active mode only. Store data in S3, later switch to filesystem, and n8n now prunes only the filesystem — the S3 objects stay, invisible to your retention settings, still on your bill.

Set pruning deliberately and keep proper error handling and monitoring on the workflows that matter, and database mode carries far more than people expect.

What We Actually Recommend

We run self-hosted n8n with north of 200 workflows on it, for our own operations and for client automation, and this is the decision tree we use:

• Single process, any volume: filesystem. Persistent volume, done. Don't overthink it.
• Queue mode, Community Edition: database, with EXECUTIONS_DATA_MAX_AGE at 72 hours and success executions not saved. This covers the large majority of agency deployments, and it covers them well.
• Queue mode, files regularly above ~50 MB: you need external storage, which means a Business or Enterprise license. Price the license against the engineering time you'll spend nursing a bloated Postgres, because that comparison usually settles it.
• Already on S3: verify the lifecycle rule exists today, and verify no lifecycle rule exists for execution data. Both take two minutes.

The broader point: binary data configuration is one of the handful of settings where the default is actively wrong for production, and where the failure mode is a crash or a silent disappearance rather than a helpful error. It belongs on the same checklist as your database choice and your worker sizing, which is the same conversation as self-hosted versus n8n Cloud.

Get it right once and you never think about it again.

Get a Free Automation Audit

If you're running self-hosted n8n and you're not sure whether your binary data configuration is a problem waiting to happen, we'll look at it. Our n8n workflow automation team reviews your execution mode, storage configuration, pruning settings and error handling, then tells you plainly what will break first and what it would cost to fix.

Get a free automation audit — no call required, and we'll send the findings in writing.

Configuration details in this article reference n8n's official documentation on handling binary data and external storage, current as of September 2026.