Scaling n8n to 100,000 Workflows/Day: Eliminating PostgreSQL Deadlocks with Redis Queue Mode
How to scale self-hosted n8n from single-instance execution to a multi-worker Redis queue architecture, eliminating database bottlenecks and lock contention.
When running n8n in default single-process mode, workflow executions write state directly to the main database. Once your automation traffic exceeds 10,000 executions per day—such as processing bulk webhooks, syncing CRM data, or streaming AI agent steps—PostgreSQL starts experiencing extreme connection exhaustion, table locks, and memory bloat.
To scale n8n reliably to 100,000+ executions/day, you must decouple workflow triggers from execution workers using n8n Queue Mode backed by Redis.
Multi-Worker n8n Queue Architecture
# docker-compose.queue.yml
services:
n8n-main:
image: n8nio/n8n:latest
environment:
- EXECUTIONS_MODE=queue
- QUEUE_BULL_REDIS_HOST=redis
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
n8n-worker-1:
image: n8nio/n8n:latest
command: worker --concurrency=10
environment:
- EXECUTIONS_MODE=queue
- QUEUE_BULL_REDIS_HOST=redis
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
n8n-worker-2:
image: n8nio/n8n:latest
command: worker --concurrency=10
environment:
- EXECUTIONS_MODE=queue
- QUEUE_BULL_REDIS_HOST=redis
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
Frequently Asked Questions
Why does n8n experience PostgreSQL deadlocks at scale?
In default single-process mode, hundreds of concurrent workflow executions compete for row locks in the executions table, exhausting database connections.
How does n8n Redis Queue Mode solve execution bottlenecks?
Queue Mode routes incoming triggers to Redis BullMQ, distributing tasks across stateless worker nodes with controlled concurrency and zero DB lock contention.
Subscribe to the Technical Newsletter
Get deep-dives into DevOps, Kubernetes, Linux performance, and self-hosted AI architecture.