Binary Data: Filesystem/S3 Instead of Database

When an n8n workflow processes PDFs, images, or other files, n8n has to temporarily store this binary data somewhere before passing it on to the next node. Without explicit configuration, this data ends up in memory or, depending on the operating mode, in the database itself, which quickly leads to memory problems and a bloated database with larger files or many parallel executions. The official n8n documentation on Handling binary data at scale therefore recommends switching production instances to filesystem mode or, with self-hosted enterprise licenses, to external S3 storage. As of: July 2026.

Why the database is unsuitable for binary data

By default, n8n keeps binary data in memory, which according to the documentation can lead to crashes with large files. If an instance runs in queue mode with multiple workers, n8n does not support filesystem mode, and the binary data must instead be stored in database mode. The problem: a relational database is designed for many small, structured rows, not for large binary blobs. As the stored files grow, the database grows noticeably along with them, which slows down backups, replication, and normal queries. This is exactly where switching to filesystem or S3 storage comes in.

Filesystem mode: the pragmatic first step

For self-hosted n8n instances outside of queue mode, filesystem mode is the simplest solution. It can be activated via the environment variable N8N_DEFAULT_BINARY_DATA_MODE with the value filesystem, causing n8n to write binary data to disk instead of memory. The storage location can be customized via N8N_BINARY_DATA_STORAGE_PATH, and by default it is located under N8N_USER_FOLDER/binaryData. In addition, N8N_AVAILABLE_BINARY_DATA_MODES defines which modes are available at all, as a comma-separated list with filesystem as the default value. Details on all variables are listed in the n8n documentation on environment variables for binary data. Important for operators: if the instance runs in queue mode, this approach cannot be used according to the documentation, leaving only database mode or S3.

S3 mode: external storage for scaling deployments

Anyone running n8n at a larger scale or relying on multiple worker instances can store binary data in an S3-compatible object store. According to the n8n documentation on external storage, this mode is only available on self-hosted enterprise plans and requires a valid enterprise license key, without which the instance will not even start in S3 mode. Configuration is done via several variables.

• N8N_EXTERNAL_STORAGE_S3_HOST: the S3 endpoint, for example s3.us-east-1.amazonaws.com
• N8N_EXTERNAL_STORAGE_S3_BUCKET_NAME: the name of the bucket
• N8N_EXTERNAL_STORAGE_S3_BUCKET_REGION: the region, from version 2.6.4 only alphanumeric characters and hyphens, if no region is specified the value auto is sufficient
• N8N_EXTERNAL_STORAGE_S3_ACCESS_KEY and N8N_EXTERNAL_STORAGE_S3_ACCESS_SECRET: credentials for the bucket
• N8N_EXTERNAL_STORAGE_S3_AUTH_AUTO_DETECT: optionally set to true to automatically detect credentials, for example via an IAM role

The mode is activated via N8N_AVAILABLE_BINARY_DATA_MODES=filesystem,s3 together with N8N_DEFAULT_BINARY_DATA_MODE=s3, followed by a restart of the instance. Binary data then ends up structured under workflows/{workflowId}/executions/{executionId}/binary_data/{binaryFileId} in the bucket.

Preparing the migration properly

Before switching, you should set up the bucket along with the IAM policy for the necessary S3 actions and set a lifecycle rule that automatically deletes old binary data, because according to the documentation n8n does not take over this cleanup automatically. Another point that is easily overlooked: pruning of binary data only ever affects the currently active mode. If you switch from database mode to filesystem or S3 mode, older binary data remains in the previous storage location and must be cleaned up separately. Anyone running an n8n instance in production with growing data volume should plan this switch early rather than only reacting once the database becomes noticeably slower. NordFlux supports n8n setup, including a storage configuration that matches the actual data volume.

Frequently asked questions about binary data in n8n

What is the difference between filesystem mode and S3 mode?

Filesystem mode writes binary data to the local disk of the n8n server and is suitable for individual instances that do not run in queue mode. S3 mode outsources the data to an external object store and is intended for distributed setups with multiple workers, but requires a self-hosted enterprise license.

Do I necessarily need an enterprise license for S3 mode?

Yes. According to the n8n documentation, the instance will not start in S3 mode without a valid enterprise license key. For smaller setups not running in queue mode, the free filesystem mode is usually sufficient.

Does filesystem mode also work in queue mode?

No. n8n does not support filesystem mode in combination with queue mode. Operators with multiple workers must instead use either database mode or, with the appropriate license, S3 mode.

What happens to binary data that has already been stored when the mode is switched?

They are not automatically migrated or deleted. Pruning always only works on the currently configured mode, so old files in the previous storage location remain and must be cleaned up manually.