n8n performance drops after scaling horizontally – why more workers isn’t enough

Who this is for: Site reliability engineers, platform engineers, or DevOps teams that have already deployed n8n in a Kubernetes (or similar) environment and are now adding pods to increase capacity. We cover this in detail in the n8n Performance Degradation & Stability Issues Guide.

Quick Diagnosis & Fix

Quick test – After applying the appropriate remedy, re‑run a load test (e.g., hey -c 200 -n 10000 http://<lb>/webhook). Latency should drop and error rate stay below 1 %.

1. Horizontal Scaling Basics

If you encounter any n8n throughput plateau adding workers stops helping resolve them before continuing with the setup.

EEFA Note: n8n was originally built for “single‑node dev” use‑cases. Scaling without converting these components creates hidden contention points that manifest as performance drops.

2. Common Bottlenecks After Scaling

2.1 Database Saturation

PostgreSQL Upgrade Example

# Set environment variables for an external HA Postgres
export N8N_DB_TYPE=postgresdb
export N8N_DB_POSTGRESDB_HOST=<aurora-endpoint>
export N8N_DB_POSTGRESDB_PORT=5432
export N8N_DB_POSTGRESDB_USER=<user>
export N8N_DB_POSTGRESDB_PASSWORD=<password>

Enable pgbouncer Pooler

helm install pgbouncer bitnami/pgbouncer \
  --set postgresql.host=<aurora-endpoint> \
  --set postgresql.port=5432

# Point n8n to the pooler
export N8N_DB_POSTGRESDB_HOST=pgbouncer.default.svc.cluster.local

2.2 Queue Mis‑configuration

Deploy Redis (replicated)

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install redis bitnami/redis --set architecture=replication

Configure n8n to use Redis (first half)

# values.yaml – queue mode
env:
  - name: N8N_QUEUE_MODE
    value: "redis"

Configure n8n to use Redis (second half)

  - name: N8N_REDIS_HOST
    value: "redis-master.default.svc.cluster.local"
  - name: N8N_REDIS_PORT
    value: "6379"
  - name: N8N_REDIS_DB
    value: "0"

EEFA Warning: Enable Redis persistence (appendonly yes) and ACLs; otherwise a single node failure can lose queued executions.

2.3 Sticky Sessions & Webhook Routing

Option A – Enable Sticky Sessions (K8s Service)

apiVersion: v1
kind: Service
metadata:
  name: n8n
spec:
  selector:
    app: n8n
  ports:
  - protocol: TCP
    port: 80
    targetPort: 5678
  sessionAffinity: ClientIP   # <-- enable sticky sessions

Option B – Stateless Webhooks

export N8N_DISABLE_PROXIES=true
# Add to deployment env:
- name: N8N_DISABLE_PROXIES
  value: "true"

2.4 Memory Leaks in Long‑Running Workflows

Example Settings

export N8N_MAX_BINARY_DATA_SIZE=5mb
export N8N_EXECUTIONS_PROCESS=worker
export N8N_WORKER_CONCURRENCY=5
export N8N_MAX_EXECUTION_TIMEOUT=300   # seconds

2.5 CPU Throttling & Pod Resource Limits

EEFA Tip: Use the Horizontal Pod Autoscaler (HPA) with a custom metric (n8n_executions_per_second) instead of only CPU.

Resource & Autoscaling Manifest (split for readability)

resources:
  requests:
    cpu: "1"
    memory: "1Gi"
  limits:
    cpu: "2"
    memory: "2Gi"

autoscaling:
  enabled: true
  minReplicas: 3
  maxReplicas: 12
  targetCPUUtilizationPercentage: 70
  metrics:
  - type: Pods
    pods:
      metric:
        name: n8n_executions_per_second
      target:
        type: AverageValue
        averageValue: "200"

3. Step‑by‑Step Stabilization Guide

3.1 Audit Your Current Stack

# Identify DB type
echo $N8N_DB_TYPE   # should be "postgresdb" in production

# Verify queue mode
echo $N8N_QUEUE_MODE   # must NOT be "memory"

# Check LB session affinity
kubectl get svc n8n -o yaml | grep sessionAffinity

If any command returns a default (sqlite, memory, None), you are in a bottleneck zone.

3.2 Deploy a Distributed Queue (Redis)

1. Install Redis (see 2.2).
2. Add env vars (see 2.2 snippets).
3. Restart n8n pods:

   kubectl rollout restart deployment n8n
   

3.3 Upgrade to HA PostgreSQL

3.4 Enforce Sticky Sessions or Stateless Webhooks

*Choose one approach that matches your ingress controller.*

• Sticky Sessions – apply the Service manifest from 2.3 Option A.
• Stateless Webhooks – add N8N_DISABLE_PROXIES=true to the deployment env (see 2.3 Option B).

3.5 Tune Resources & Enable Autoscaling

1. Update the deployment with the resources block (see 2.5).
2. Enable the HPA using the autoscaling block (see 2.5).
3. Apply changes:

   helm upgrade --install n8n . -f values.yaml
   

4. Troubleshooting Checklist

If any metric exceeds the expected range, revisit the corresponding configuration block in Section 3.

5. Production‑Ready Best Practices (EEFA)

preStop:
  exec:
    command: ["curl", "-X", "POST", "http://localhost:5678/healthz/shutdown"]

Conclusion

Performance regressions after horizontal scaling almost always stem from five core regressions: database saturation, an in‑memory queue, missing sticky sessions, memory‑leaky workflows, and CPU throttling. By auditing each component, migrating to distributed services (HA PostgreSQL, Redis), enforcing session affinity or stateless webhooks, tuning pod resources, and applying the EEFA best practices above, you can scale n8n horizontally without sacrificing latency or reliability. Validate each change with load‑testing and the troubleshooting checklist, then let the autoscaler handle traffic spikes while your underlying services stay robust. Happy automating!