Here's a quick gut check: has your n8n workflow ever been hit by 2,000 users at once? If not, you don't know it's production-ready. You just know it hasn't failed yet. By default, n8n runs everything — UI, triggers, execution — through one main instance. Fine with 20 users. At 2,000, that instance chokes: requests pile up, executions time out, the editor lags. The fix is Queue Mode: → Main instance receives the trigger, doesn't execute it → Job goes into Redis (the queue) → Workers pull jobs and run them in parallel → Results get written to a shared PostgreSQL database If a worker crashes mid-job, another one picks it up. Main instance stays untouched, so your editor and webhooks never freeze. One thing most people miss: scaling isn't just "add more workers." It's worker count × concurrency. Get concurrency wrong, and more workers can strain your database faster than they add capacity. Full visual breakdown attached — Regular Mode vs Queue Mode, side by side. Running n8n in production and still on Regular Mode? Worth testing before your users force the question. Drop a comment if you want to walk through your setup.

Back to our weekly calls