Short answer: Treat n8n scaling as an execution design problem: decide where executions run, how workers receive jobs, how data is stored, and how failures are observed. Queue mode becomes useful when one process can no longer provide predictable throughput.

n8n&#8217;s execution engine processes workflows sequentially through a<br /> main process or distributed via queue mode with Redis as the central<br /> broker. This architecture supports horizontal scaling from a single<br /> SQLite instance to hundreds of workers backed by PostgreSQL. Below<br /> you’ll find the internals, scaling controls, and platform comparisons<br /> that help you choose the right production setup.

How does n8n’s execution engine process workflows?

The n8n execution engine processes nodes sequentially from the<br /> trigger onward, passing a JSON context between steps. It allocates<br /> memory per execution, records input/output snapshots, and enforces<br /> a configurable timeout (default 300 seconds). On failure it stores<br /> a full stack trace and triggers the linked error workflow.<br />

[1]

A deeper dive into how the engine spawns processes and manages<br /> memory is available in our<br />

engine, queue mode & memory guide.

The engine’s design is also the foundation for every<br /> <a class=”spoke-link” href=”https://n8n.spot/types-of-n8n-workflows-triggers-branches-sub-workflows/”>workflow type</a>.

How does n8n queue mode distribute workflow executions across workers?

Queue mode replaces the built‑in execution with a Redis‑backed<br /> queue. The main n8n instance enqueues jobs; dedicated worker<br /> processes dequeue and run them independently. Each worker runs<br /> the full execution engine in its own Node.js process, isolated<br /> from the main instance, enabling parallel execution.<br />

[1]

This separation prevents a single stuck workflow from blocking<br /> others. You can add workers on separate machines, all connected<br /> to the same Redis and database. For configuration details see<br /> <a class=”spoke-link” href=”https://n8n.spot/n8n-scaling-concurrency-postgresql-worker-queue-configuration/”>scaling, concurrency &#038; queue configuration</a>.

What is the minimum Redis version for n8n queue mode?

n8n queue mode requires <strong>Redis 6.0 or higher</strong> to<br /> support the BullMQ job queue library, which relies on atomic Lua<br /> scripting available only from Redis 6.0 onward. You must also<br /> set <code>QUEUE_BULL_REDIS_HOST</code> and port env variables.<br /> The database remains PostgreSQL for production setups.<br />

[1]

Using an older Redis version will cause connection failures.<br /> Self‑hosted admins should pin the Redis version in their Docker<br /> Compose file to avoid accidental downgrades.

How do you configure n8n worker concurrency and memory limits?

Worker concurrency is controlled by the environment variable<br />

N8N_CONCURRENCY_PRODUCTION_LIMIT (default 10).

Each concurrent execution consumes additional memory; n8n<br /> recommends at least 256 MB of RAM per execution slot. You can<br /> also limit memory per Node.js process with <code>–max-old-space-size</code>.<br />

[2]

For large‑scale deployments, pair this configuration with the<br />

scaling & concurrent worker guide

and benchmark your workload to tune the limit.

What database options does n8n support for production and development?

n8n supports SQLite (default for local/desktop) and PostgreSQL<br /> for production workloads. SQLite works for single‑user testing<br /> but cannot handle concurrent writes under queue mode. PostgreSQL<br /> is required for multi‑worker environments and is recommended for<br /> any self‑hosted or cloud deployment above 5,000 exec/month.<br />

[3]

The selection directly impacts scaling capabilities; explore<br />

n8n vs Zapier vs Make

to see how database sovereignty compares to SaaS competitors.

How can you scale n8n horizontally with queue mode and PostgreSQL?

Horizontal scaling is achieved by deploying multiple worker<br /> instances behind a shared Redis broker and a single PostgreSQL<br /> database. The main n8n process serves the editor and API; it<br /> enqueues all executions to Redis. Workers on separate VMs pull<br /> jobs and execute them, scaling linearly with CPU cores.<br />

[1]

To prevent overloading, set <code>N8N_CONCURRENCY_PRODUCTION_LIMIT</code><br /> per worker, and monitor Redis memory. For a full production<br /> blueprint, read our<br /> <a class=”spoke-link” href=”https://n8n.spot/n8n-scaling-concurrency-postgresql-worker-queue-configuration/”>detailed scaling configuration guide</a>.