Boa parte da lentidão do n8n vem de configuração. Três verificações mostram se o upgrade resolve ou só adia o problema.
- Histórico de execuções acumulado deixa o banco e a interface lentos.
- Arquivos grandes na memória derrubam o processo.
- Um fluxo pesado no mesmo processo atrasa os webhooks.
Os fluxos começaram a atrasar e a primeira ideia é contratar uma máquina maior. Antes, vale gastar meia hora nestas três verificações, que explicam a maioria dos casos.
Banco cheio de execuções antigas
Cada execução salva fica no banco com os dados de cada nó. Em fluxos que rodam a cada minuto, isso vira gigabytes em poucas semanas. Se você usa Postgres, veja o tamanho com:
SELECT pg_size_pretty(pg_database_size(current_database()));Se o número assustar, ajuste a limpeza automática com as variáveis EXECUTIONS_DATA_MAX_AGE e EXECUTIONS_DATA_PRUNE_MAX_COUNT. Em fluxos de alto volume, EXECUTIONS_DATA_SAVE_ON_SUCCESS=none guarda só as execuções que falharam.
Arquivos grandes na memória
PDFs, planilhas e imagens que passam pelo fluxo ficam na memória por padrão, e um arquivo grande pode derrubar o processo inteiro. A variável N8N_DEFAULT_BINARY_DATA_MODE=filesystem grava esses dados em disco.
Um fluxo pesado segurando os outros
No modo padrão, tudo roda no mesmo processo, e uma execução que processa milhares de itens atrasa os webhooks. Dá para limitar a concorrência ou passar para o modo fila, com workers separados.
Quando o upgrade resolve
Depois dos ajustes, meça de novo por uma semana com docker stats ou com as métricas do próprio n8n (N8N_METRICS=true). Se a CPU continua alta nos picos, a carga é real e a máquina maior resolve. Se o n8n divide espaço com outras ferramentas, veja se compensa juntar tudo numa máquina só.
