I Run n8n in Both Modes. Queue Mode's Peak Load: 19 Jobs

Description and use

The article compares single‑process and queue modes for n8n. Queue mode handled 76,100 runs in a week, using ~900 MiB more RAM and suffering migration race issues, but it offers crash isolation and graceful restarts. The decision should be based on run duration and resource impact rather than sheer execution count.

Problem

Deciding whether to run n8n in single‑process or queue mode when handling high execution volume and ensuring availability.

Outcome

Queue mode handled 76,100 executions with only 19 concurrent jobs, providing crash isolation and restart safety at the cost of ~900 MiB extra RAM and migration race complexity.

Workflow

• 1. Deploy two identical n8n instances (queue and single‑process).
• 2. Run both for 7 days, collecting execution counts, concurrency, RAM usage, and success rates via SQL queries and docker stats.
• 3. Analyze peak concurrent executions (queue: 19, single: 1).
• 4. Evaluate RAM consumption (queue: 456+445 MiB, single: 507 MiB).
• 5. Identify benefits: crash isolation, restart behavior, scaling path.
• 6. Identify costs: migration race, silent worker failures, extra RAM.
• 7. Decide mode based on workload characteristics (sub‑second traffic vs. long/memory‑heavy runs).

Evidence

At the single busiest moment of those 76,100 runs, exactly 19 executions were in flight at once.

Source

Queue mode costs me roughly 900 MiB of n8n processes to do what the regular instance does in 507 MiB.

Source

The migration race. Every version upgrade, docker compose up -d starts main and worker together, and both immediately try to run database migrations on the same Postgres.

Source