Postgres vs SQLite no n8n: qual banco escolher para self-hosted (e quando trocar)
- SQLite é ótimo para começar rápido, mas pode sofrer em concorrência e crescimento do arquivo
- Postgres dá mais previsibilidade operacional (backup, restore, tuning, observabilidade)
- O “melhor” banco depende do padrão de carga: simultaneidade, tamanho do histórico e disciplina de backup
- Migrar cedo demais aumenta complexidade; migrar tarde demais vira incidente
O que muda na prática (não no PowerPoint)
No n8n, o banco não é detalhe: ele segura credenciais, execuções, histórico, estados e parte do que você usa para depurar problemas. A escolha afeta o que você sente no dia a dia: editor abrindo lento, execuções concorrendo entre si, backup que restaura de verdade e tempo para achar a causa de um erro.
SQLite e Postgres são ótimos no que se propõem. O problema é usar o “ótimo” no contexto errado: SQLite como se fosse um banco transacional multiusuário 24/7, ou Postgres para um laboratório que você liga uma vez por semana.
Comparativo direto: SQLite vs Postgres no n8n
Abaixo está o comparativo que costuma resolver 80% das dúvidas. Não é “um é melhor”, é “um te cobra em lugares diferentes”.
| Critério | SQLite (arquivo) | Postgres (servidor) |
|---|---|---|
| Setup | Mais simples: geralmente menos variáveis e serviços | Mais peças: instância, usuário, rede, persistência |
| Concorrência (muitas execuções ao mesmo tempo) | Pode virar gargalo dependendo do padrão de escrita/leitura; risco maior de lock/contensão | Lida melhor com múltiplas conexões e escrita concorrente |
| Recuperação e restauração | Backup parece fácil (copiar arquivo), mas restauração consistente exige cuidado com processo em execução | Backups e restores mais tradicionais (dump/snapshot), com rotinas mais consolidadas |
| Crescimento do histórico de execuções | Arquivo pode crescer e ficar mais sensível a IO; manutenção costuma ser mais “na unha” | Melhor para grandes volumes e manutenção planejada |
| Observabilidade | Menos recursos nativos para analisar gargalos; costuma virar “tentativa e erro” | Ecossistema forte de métricas, logs, tuning e diagnósticos |
| Risco operacional típico | Descobrir limite em produção (travamentos/lentidão) quando a automação pega tração | Complexidade de configuração e manutenção se a equipe não tem rotina de DB |
Sinais reais de que está na hora de migrar para Postgres
Não espere “quebrar” para decidir. Em automação, o custo não é só o banco: é o fluxo que falha e o time apagando incêndio. Alguns sinais aparecem antes do desastre.
Quando SQLite ainda é a escolha certa (sim, acontece bastante)
SQLite é subestimado por quem só olha para cenário enterprise. Para muito projeto pequeno/médio — principalmente em fase de validação — ele reduz complexidade e acelera entrega.
Perfis em que SQLite tende a dar conta: laboratório, POC, automações internas com baixo volume, operação com pouca simultaneidade e retenção curta de execuções (limpeza de histórico bem ajustada).
Checklist de decisão (o que eu perguntaria antes de escolher)
Se você responder “sim” para várias perguntas do bloco Postgres, a conta fecha rápido.
Armadilhas comuns (que fazem a decisão parecer mais difícil do que é)
Alguns erros fazem a discussão virar religião. O objetivo aqui é evitar que o banco vire o bode expiatório de problemas de arquitetura ou de operação.
Armadilhas que aparecem com frequência: culpar SQLite por lentidão causada por histórico infinito; migrar para Postgres sem ajustar retenção/limpeza; não testar restore; colocar o banco no mesmo disco saturado do restante da VPS; e mudar várias coisas ao mesmo tempo (aí você não sabe o que melhorou/piorou).
Perguntas frequentes
SQLite no n8n é “errado” para produção?
Qual opção é mais rápida no n8n: Postgres ou SQLite?
Se eu começar com SQLite, vou conseguir migrar depois?
O que pesa mais: trocar para Postgres ou ajustar retenção de execuções?
Leia também
Como migrar o n8n do SQLite para Postgres (sem dor de cabeça)
Passo a passo para sair do SQLite no n8n self-hosted e ir para Postgres com menos risco: checklist, ordem correta, pontos de atenção e validação pós-migração.
Ler →
Como rodar n8n em Docker Compose com Postgres e HTTPS (sem dor de cabeça)
Aprenda a subir o n8n self-hosted com Docker Compose, Postgres e HTTPS (Traefik ou Nginx). Checklist de variáveis, persistência, webhooks e erros comuns no Brasil.
Ler →
Como fazer backup do n8n self-hosted e restaurar sem perder workflows
Guia prático de backup e restauração do n8n self-hosted: exportar workflows e credenciais via CLI, dump do PostgreSQL, a chave de criptografia que não pode faltar e como automatizar tudo.
Ler →
n8n self-hosted vs n8n cloud: qual vale mais a pena para o seu caso?
Compare n8n self-hosted e n8n cloud em 2026: preços, limites, facilidade de uso e quando cada opção faz sentido para iniciantes, agências e empresas.
Ler →