Oi pessoal
Estou rodando n8n com múltiplos workers, e conforme a concorrência aumenta, estou começando a pensar sobre gerenciamento de conexões PostgreSQL.
Minha arquitetura é mais ou menos:
Load Balancer
↓
Múltiplos n8n Workers
↓
PostgreSQL
Minha preocupação é que se cada worker abre múltiplas conexões de banco de dados, o banco de dados pode eventualmente atingir seu limite de conexões, afetando o desempenho e a estabilidade dos workflows.
Estou considerando usar um connection pooler como PgBouncer, mas gostaria de entender como outros gerenciam isso em produção.
Para quem está rodando PostgreSQL com deployments n8n de alta concorrência:
Como você decide a configuração correta de max_connections?
Você usa um connection pooler como PgBouncer, ou o comportamento padrão do PostgreSQL é suficiente?
Como você monitora o esgotamento de conexões antes de se tornar um problema?
Você achou que aumentar a contagem de workers ou otimizar queries teve um impacto maior no desempenho geral do banco de dados?
Descreva o problema/erro/pergunta
Qual é a mensagem de erro (se houver)?
Por favor, compartilhe seu workflow
(Selecione os nós no seu canvas e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o workflow.)
Oi @Keira_Becky Uma boa abordagem é otimizar o uso de conexões antes de aumentar o limite de conexões.
Abordagem recomendada
Em vez de aumentar continuamente max_connections, use um pooler de conexões como PgBouncer para reutilizar conexões existentes de forma eficiente.
n8n Workers
↓
PgBouncer
↓
PostgreSQL
Isso reduz a sobrecarga de conexão e ajuda o PostgreSQL a lidar com maior concorrência de forma mais eficiente.
Melhores práticas
Use pool de conexões para múltiplos workers
Defina max_connections com base na CPU e memória do seu servidor
Monitore conexões ativas, inativas e em espera
Otimize consultas lentas antes de adicionar mais workers
Fique atento a: Conexões ativas
Conexões inativas
Tempo de espera de conexão
Latência de consulta
Uso de CPU e memória
Em produção, pool de conexões e otimização de consultas geralmente proporcionam melhor escalabilidade do que simplesmente aumentar o limite de conexões do PostgreSQL.
Em um deployment padrão do n8n, a fórmula não é simplesmente workers * 1. Cada processo worker pode manter um pool de conexões.
A Lógica de Cálculo:
Instância Principal: Precisa de algumas conexões para a UI, API e scheduler.
Workers: Cada processo worker normalmente mantém um pequeno pool. Se você tem 10 workers e cada um permite um pool de 10, você está em 100 conexões só para workers.
Overhead: O Postgres aloca memória para cada conexão (aproximadamente 2-10MB dependendo de work_mem). Definir max_connections muito alto (por exemplo, 5000) sem RAM suficiente fará com que o SO mate o Postgres via OOM killer.
Recomendação: Comece com max_connections = 200-500 para deployments de médio porte. Se você ultrapassar isso, não simplesmente continue aumentando o número; migre para um pooler.
PgBouncer é para ambientes de produção com alta concorrência.
O comportamento padrão do PostgreSQL é “um processo por conexão”, o que é caro. PgBouncer atua como um proxy leve que gerencia um pool de conexões “reais” com o DB enquanto permite milhares de conexões “virtuais” dos workers do n8n.
Oi @Keira_Becky
A alavanca por processo é DB_POSTGRESDB_POOL_SIZE, que tem o padrão de 2, então a pegada é aproximadamente (processos principais + workers + processadores de webhook) vezes esse valor, e você dimensiona o banco de dados em torno dessa figura em vez de estimar pela contagem de workers. Aumente-o por processo apenas quando os workers estiverem realmente esperando no pool.
Escale executando menos workers com concorrência mais alta em vez de muitos workers com concorrência baixa. A n8n recomenda 5 ou mais por worker porque um grande número de workers com baixa concorrência esgota o pool de conexões e causa atrasos e falhas:
Depende da sua carga de trabalho, mas para a maioria das aplicações de alta concorrência, o pool de transações é geralmente preferido porque permite que as conexões sejam reutilizadas de forma mais eficiente e oferece suporte a um número maior de clientes simultâneos.
O pool de sessões pode ser uma escolha melhor se sua aplicação depende de recursos específicos da sessão, como tabelas temporárias ou variáveis de sessão, já que cada cliente mantém a mesma conexão de banco de dados durante toda a sessão.
Antes de escolher um modo, eu testaria em um ambiente de staging e verificaria se seus fluxos de trabalho n8n não dependem de comportamento específico da sessão. Depois monitore o uso de conexões, a latência de consultas e a taxa de transferência geral para confirmar que está funcionando conforme esperado.
Em geral, a melhor escolha depende de como sua aplicação usa conexões de banco de dados, portanto vale a pena validar com cargas de trabalho similares à produção antes de implantar.
