Little's law explains the 19 better than the hardware does. According to the dev.to writeup, 76,100 executions landed in a week, which is about 0.126 per second [3]. The number in flight equals arrival rate times mean residence time, so holding 19 at once implies a mean residence near 150 seconds [4]. Yet 88% of retained executions on that instance finish in under a second [4]. Both numbers hold only if the in-flight count is mostly made up of jobs that are not computing. The author says exactly that: the three longest runs in the window are AI workflows that hung on a model call and eventually errored, one for 7,320 seconds [7], and the in-flight figure also counts parent workflows sitting idle while sub-workflows run [12].
So 19 is a stall count wearing the costume of a load measurement. For it to transfer to your deployment, your nodes have to be doing close to nothing per run. That is what this traffic is: one gateway workflow in front of a WhatsApp bot took 11,880 executions a day and rejected most of them in its first node, 96% of them under a second [16]. Put real work behind the webhook, and in-flight starts mapping to CPU demand, at which point 2 vCPU [1] is the number that binds.
The price of admission is legible. The queue stack runs about 900 MiB of n8n processes against 507 MiB for the single-process box, with Redis a rounding error and the worker being a whole second n8n [5]. That is 393 MiB more, roughly 78% more resident memory [1], about a tenth of a 4 GB VPS [2]. There is no latency dividend to offset it, since a sub-second execution is sub-second in either mode and the queue only adds a Redis hop [6].
What the money buys is availability. A hung model call in single-process mode shares a process with the editor and the webhook listener, and a memory-hungry one takes everything with it; in queue mode it burns one worker slot out of five and the rest keeps flowing [8]. The author is explicit that this is an availability feature, not a performance feature [9]. Second on the list is restarts: the worker can be replaced while main keeps accepting webhooks and the queue holds jobs [10].
Two operating costs do not appear in the scaling advice. First, `docker compose up -d` starts main and worker together and both immediately attempt migrations on the same Postgres, and n8n has no cross-instance migration lock, so main wins and the worker dies with a `MigrationExecutor.executePendingMigrations` trace [13]. The fix is to wait for main to report healthy and restart the worker, which rejoins cleanly [14]. An unhealthy worker mid-upgrade also looks precisely like a half-migrated database, which is a memorable way to spend twenty minutes. Second, a dead worker fails silently: webhooks return 200, jobs enqueue, nothing runs [15].
Then the actual ceiling. n8n persists every execution by default, and the prune cap `EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000` became the effective retention window, worth 2.5 days at this write rate [17]. That implies about 20,000 retained rows a day [6], of which the no-op gateway alone is roughly 59% [7]. Sixteen active workflows had no saved executions left at all [18]. A second worker changes where a job runs and not how many rows it writes, which is why the pruning cap is the line I would read before the concurrency setting.
