- SQLite funciona bem para testes; Postgres é mais previsível para produção e concorrência.
- Migração segura começa com pausa de filas/executions e backup verificável.
- Em n8n self-hosted, a troca de banco costuma ser feita por variáveis (DB_TYPE/DB_POSTGRESDB_*) e reinício controlado.
- Valide pós-migração: credenciais, webhooks, execuções antigas e permissões.
1) Decida se é hora de sair do SQLite
Sinais comuns: aumento de volume de execuções, mais de um usuário mexendo em workflows, travamentos intermitentes, restore demorado, ou necessidade de confiabilidade maior. SQLite é ótimo pela simplicidade; Postgres tende a lidar melhor com concorrência e manutenção em produção.
2) Faça um backup que você consegue restaurar
Guarde: (a) o arquivo do SQLite (normalmente em volume persistente), (b) a pasta de dados do n8n (config e artefatos), e (c) o arquivo de deployment (docker-compose/variáveis). Se possível, teste o restore em um ambiente de homologação. Backup “feito” que não restaura é só sensação de segurança.
3) Congele escrita: pause execuções e mudanças
Antes de copiar/transferir dados, reduza o risco: pause agendamentos, desative triggers temporariamente e evite edições em workflows. O objetivo é impedir que o SQLite mude enquanto você migra, evitando inconsistências difíceis de rastrear (ex.: credenciais “sumindo”, execuções duplicadas).
4) Suba o Postgres e confirme acesso
Suba o Postgres com volume persistente e credenciais definidas. Confirme conexão (host/porta/usuário/senha/db). Dica prática: defina timezone e garanta persistência do volume; isso evita surpresas em logs e retenção de dados.
5) Aponte o n8n para Postgres (sem jogar o antigo fora)
Ajuste as variáveis de ambiente do n8n para usar Postgres e reinicie de forma controlada. Mantenha o SQLite intacto até validar tudo. Em ambientes Docker, isso normalmente significa editar docker-compose e subir novamente, observando logs de migração/inicialização.
6) Migre dados e valide o que mais quebra
O que merece validação manual: abertura do editor, lista de workflows, credenciais (principalmente integrações sensíveis), webhooks (rotas e respostas), execuções recentes e agendamentos. Rode 2–3 fluxos críticos de ponta a ponta e compare resultados com o período pré-migração.
7) Reative triggers e monitore por 24–72 horas
Reative aos poucos (comece pelos fluxos menos críticos). Monitore erros, latência, duplicidade e filas. Se aparecer erro intermitente, volte para o básico: logs, variáveis e conectividade com o Postgres. Só depois desse período faz sentido considerar remover o SQLite antigo.
SQLite vs Postgres no n8n: qual é a diferença prática
Na vida real, a diferença não é “um é melhor”, e sim “um é mais tolerante ao crescimento”. SQLite reduz complexidade (um arquivo, pronto), mas tende a sofrer quando a automação vira operação: mais execuções simultâneas, mais escrita, mais concorrência.
Postgres adiciona uma peça a mais (um serviço de banco), porém melhora previsibilidade em cenários com volume e manutenção. Para muita gente, a migração é menos sobre performance bruta e mais sobre reduzir sustos e facilitar backup/restore estruturado.
| Ponto | SQLite | Postgres |
|---|---|---|
| Setup | Simples (arquivo) | Mais componentes (serviço + credenciais) |
| Concorrência | Pode limitar em escrita concorrente | Mais robusto para múltiplas conexões |
| Operação/backup | Cópia do arquivo (cuidado com consistência) | Dump/restore e rotinas maduras |
| Quando faz sentido | Teste, PoC, baixa carga | Produção, times, volume crescente |
Checklist rápido de migração (o que não dá para esquecer)
Se você só quer um checklist enxuto, use isso como “ordem de execução” para reduzir risco:
- Anotar versão do n8n e método de deploy (Docker, VM, etc.).
- Pausar execuções e evitar edições durante a janela.
- Backup do SQLite + dados do n8n + configuração/variáveis.
- Subir Postgres com volume persistente e conexão testada.
- Apontar n8n para Postgres e reiniciar olhando logs.
- Validar: workflows, credenciais, webhooks, agendamentos e execuções.
- Reativar triggers gradualmente e monitorar por 24–72h.
Erros comuns que fazem a migração parecer “assombrada”
O que mais vejo dar trabalho não é Postgres “falhando”; é o processo ficando sem travas. Três armadilhas clássicas:
1) Migrar com o n8n ainda escrevendo no SQLite. Você copia um estado e, minutos depois, ele já mudou.
2) Confundir persistência: Postgres sem volume persistente parece funcionar… até reiniciar e “sumir tudo”.
3) Validar só o login no editor. O teste real é executar fluxos críticos, principalmente os que dependem de webhooks, filas e credenciais.
Perguntas frequentes
Preciso migrar para Postgres para rodar n8n em produção?
Vou perder histórico de execuções ao trocar de banco?
Posso manter SQLite e Postgres ao mesmo tempo e alternar?
Quais sinais indicam que meu Postgres está mal configurado para o n8n?
Leia também
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 →
Como colocar o n8n em produção: checklist de segurança, monitoramento e backup (sem susto)
Guia prático para subir n8n em produção com HTTPS, credenciais, filas/retry, logs, alertas e backup/restauração. Focado em cenários comuns no Brasil e em operação estável.
Ler →
Como dimensionar uma VPS para rodar n8n self-hosted (sem travar e sem gastar à toa)
Guia prático para escolher CPU, RAM, disco e rede de uma VPS para n8n self-hosted no Brasil, com regras simples por tipo de automação, sinais de gargalo e checklist de produção.
Ler →