Production n8n Architecture: Scaling Past 100,000 Tasks

The Single-Process Bottleneck

By default, n8n executes workflows inside its primary Node.js process. When an incoming webhook triggers a workflow that loops through a 5MB JSON array or makes twenty sequential HTTP requests:

• Event Loop Starvation: Heavy CPU parsing blocks incoming HTTP connections. Webhook senders receive 502 or 504 gateway timeouts.
• SQLite Write Locks: Concurrent executions fight for database access. SQLite throws SQLITE_BUSY: database is locked, dropping execution logs and state.
• Memory Spikes: Large binary payloads or un-chunked batch data balloon the container heap, triggering an OOM kill.

The fix is not adding more CPU cores to a single container. The fix is moving to official n8n queue mode.

The 4-Service Queue Topology

A production n8n cluster splits responsibilities across four distinct components:

1. 1. Webhook Ingress (`n8n-primary`): Runs with EXECUTIONS_PROCESS=main. Serves the web UI and listens for incoming webhooks. It never executes complex workflow logic; it serializes the trigger payload and pushes a job to Redis in under 5 milliseconds.
2. 2. Redis Broker (BullMQ): Acts as the FIFO job queue. It absorbs burst traffic, manages retries, and buffers tasks during downstream API rate limits. Configure memory limits per Redis memory optimization guidelines.
3. 3. Execution Workers (`n8n worker`): One or more stateless Node.js workers pulling jobs off Redis. You can scale workers horizontally during peak hours without touching the web listener.
4. 4. PostgreSQL 16 Engine: Replaces SQLite. Provides connection pooling and ACID write-ahead logging under PostgreSQL 16 MVCC.

Production Environment Blueprint

Here are the critical environment variables required to stabilize a queue cluster:

# Primary Container
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis.internal
QUEUE_BULL_REDIS_PORT=6379
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres.internal
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=postgres
DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
DB_POSTGRESDB_POOL_SIZE=20
N8N_ENCRYPTION_KEY=${N8N_SECRET_KEY}

# Automated Pruning (Prevents Postgres Disk Bloat)
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168
EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000

# Worker Container (Executed via: n8n worker)
N8N_CONCURRENCY_PRODUCTION_LIMIT=10

Setting EXECUTIONS_DATA_PRUNE=true with a 7-day window (168 hours) keeps your PostgreSQL database under 5GB indefinitely, even at 100,000 monthly executions.

36-Month Cost Comparison (100,000 Tasks/Mo)

Here is how running 100,000 monthly automation tasks compares over a 3-year timeline:

A queue cluster running on developer cloud infrastructure cuts three-year expenses by over $20,000 compared to legacy SaaS. For more background on pricing mechanics, review our guide to Task-Based vs. Execution Billing.

Model Your Infrastructure Costs

Calculate your exact 36-month software TCO based on event volume and team size: