- O problema real não é “salvar dados”, é manter estado entre execuções (idempotência) para evitar duplicatas e retrabalho.
- Supabase dá Postgres gerenciado + REST (e outros recursos), com camada simples para CRUD; ótimo para começar e crescer sem refazer tudo.
- Troque planilha por banco quando você precisar de: consulta rápida por chave, histórico por evento, concorrência, e regras de unicidade.
- No n8n, o padrão é: buscar (SELECT) → decidir (IF) → inserir/atualizar (INSERT/UPDATE) → registrar processamento (log).
1) Defina o “estado” que seu fluxo precisa lembrar
Antes de conectar qualquer coisa, escreva em uma frase o que o fluxo precisa saber amanhã. Exemplos comuns: “já processei esse pedido?”, “esse lead já foi contatado?”, “qual foi a última mensagem enviada?”, “qual etapa do onboarding ele está?”. Esse estado vira uma tabela (ou duas) no Supabase.
2) Modele uma tabela mínima (e chaves únicas) para matar duplicata
Crie uma tabela com um identificador único do mundo real (ex.: lead_id do CRM, email, phone normalizado, order_id). A regra prática: se dá para criar uma restrição de unicidade, você evita que o fluxo insira a mesma coisa duas vezes quando o webhook repetir ou quando o cenário rodar em paralelo.
3) Crie um “registro de processamento” (ledger) para idempotência
Além da tabela de dados, tenha um ledger simples com: event_key (único), fonte, timestamp e status. O event_key pode ser algo como “crm:lead:12345:welcome_v1”. O n8n consulta o ledger; se já existe, ele não repete a ação. Isso resolve o clássico “enviou duas mensagens” quando o gatilho dispara mais de uma vez.
4) Conecte o n8n ao Supabase via HTTP (REST) ou Postgres
Existem dois caminhos comuns: (a) chamar a API REST do Supabase com um HTTP Request no n8n (bom quando você quer simplicidade e controle por tabela), ou (b) usar conexão Postgres (bom para SQL mais livre). Se você não tiver certeza, comece pela REST: você aprende rápido o padrão GET/POST/PATCH e já resolve 80% dos casos.
5) Padrão de fluxo: Buscar → Decidir → Gravar → Confirmar
Monte o fluxo sempre no mesmo esqueleto para não se perder: primeiro faz SELECT/GET pela chave, depois um IF (existe? está em qual status?), então INSERT/UPDATE, e por fim grava no ledger (ou atualiza status). O ganho não é só técnico — é operacional: você consegue debugar e auditar.
6) Trate concorrência e reprocessamento como regra, não exceção
Assuma que o fluxo vai rodar duas vezes para o mesmo evento: reenvio de webhook, clique duplo, timeout, retry. O banco (unicidade + ledger) é seu “freio ABS”. Sem isso, você passa a depender de sorte e de planilha travando no pior horário.
7) Logue o que importa para suporte e auditoria
Guarde o mínimo para entender o que aconteceu: event_key, payload resumido (ou referência), resposta do serviço externo, erro e timestamp. Não é sobre “big data”; é sobre conseguir responder em 2 minutos: “foi enviado?”, “quando?”, “por quê falhou?”.
A parede que todo mundo encontra: “esse lead já entrou?”
Quase todo fluxo começa simples: chegou um lead → manda mensagem → cria tarefa. Aí você cresce um pouco e começa a fazer perguntas que uma automação madura precisa responder: “já enviei isso antes?”, “qual etapa ele está?”, “quando foi o último contato?”, “quantas tentativas já fiz?”.
Esse é o momento em que planilha deixa de ser armazenamento e vira lógica de controle. E planilha como controle de estado costuma falhar do jeito mais caro: duplicando envio, perdendo linha, ficando lenta, criando race condition (duas execuções escrevendo ao mesmo tempo) e virando um ‘banco de dados’ sem garantias.
Por que Supabase é o par natural do n8n (na prática, não no marketing)
O n8n é excelente em orquestrar: receber evento, chamar APIs, transformar dados, decidir caminhos. O que ele não deve fazer é “inventar um banco” dentro do workflow. Quando você precisa persistir estado, entra um banco de verdade.
O Supabase costuma encaixar bem porque entrega Postgres gerenciado (um banco relacional maduro) e uma forma acessível de ler/gravar dados por API. Para começar, normalmente existe um nível gratuito (as regras e limites mudam com o tempo; confirme no site do Supabase antes de planejar produção).
Tradução para o dia a dia: você usa o n8n como cérebro do processo e o Supabase como memória confiável.
Planilha vs banco: quando a troca deixa de ser ‘frescura’ e vira requisito
Se o seu fluxo só registra um relatório semanal, planilha pode bastar. Mas se a planilha está sendo usada para decidir se o fluxo vai agir (ou não), você já está no terreno em que banco de dados faz diferença.
| Sinal no fluxo | O que costuma acontecer com planilha | O que o Postgres (Supabase) resolve |
|---|---|---|
| Você consulta por uma chave (‘email’, ‘lead_id’, ‘order_id’) | Busca lenta, risco de erro humano, padronização frágil | Índices e consultas consistentes |
| Duas execuções podem rodar juntas | Duplicata (duas linhas, dois envios) | Chave única + upsert/controle transacional |
| Você precisa de histórico por evento | Abas viram ‘logs’, difícil auditar | Tabela de ledger com rastreabilidade |
| Você quer regras (‘status’, ‘tentativas’, ‘cooldown’) | Fórmulas e gambiarras | Modelo relacional com campos e constraints |
O desenho de tabelas que mais evita duplicata (e dor de cabeça)
Se você só fizer uma coisa, faça esta: tenha uma chave única que representa o ‘mundo real’ e um ledger de processamento.
Exemplo de estrutura mínima (adapte para seu caso):
- Tabela leads: id, source, external_id (único), email (opcional único), phone_normalized (opcional único), status, created_at, updated_at
- Tabela events_ledger: id, event_key (único), lead_external_id, flow_name, status (processed/failed), last_error, processed_at
Padrão de fluxo no n8n (o esqueleto que funciona)
O objetivo aqui é transformar o banco em ‘porteiro’ do seu fluxo: antes de enviar mensagem, criar negócio ou disparar qualquer ação irreversível, você pergunta ao Supabase se aquilo já foi processado.
Um roteiro típico:
- Trigger: webhook/cron/integração
- Normalize: padroniza email/telefone/ids
- Lookup: consulta no Supabase (por external_id/email/phone)
- IF: existe e já está processado? (ou status impede ação?)
- Write: insere/atualiza lead e registra event_key no ledger
- Act: faz a ação externa (mensagem, CRM, faturamento)
- Finalize: atualiza ledger para processed (ou failed com erro)
REST do Supabase vs SQL direto: como escolher sem complicar
Se seu fluxo é majoritariamente CRUD (buscar por id, inserir, atualizar status), a REST do Supabase via HTTP Request no n8n costuma ser suficiente e bem previsível.
Se você precisa de joins, agregações, relatórios internos ou regras mais elaboradas, SQL direto (Postgres) tende a ficar mais simples do que empilhar várias chamadas REST.
Na dúvida, comece REST e migre partes específicas para SQL quando aparecer a necessidade. O erro comum é tentar começar ‘avançado’ e travar no setup.
O que muda quando você sai da planilha: manutenção, confiabilidade e debug
O ganho não é só performance. É comportamento. Com banco, você consegue impor regras (unicidade), fazer auditoria (ledger) e reduzir o ‘mistério’ quando algo dá errado.
Na prática editorial do Automação Hoje, o padrão que mais reduz chamados é: (1) event_key único, (2) tabela de status, (3) log de erro por tentativa. Isso transforma automação de “tomara que rode” em “sei exatamente o que aconteceu”.
Perguntas frequentes
Quando exatamente devo trocar a planilha por Supabase no n8n?
Preciso programar para usar Supabase com n8n?
Como evito que o n8n dispare a mesma ação duas vezes?
Supabase é “bom o bastante” para produção ou é só para protótipo?
Leia também
n8n self-hosted e LGPD: onde ficam seus dados e como ficar em conformidade
Rodar o n8n no seu próprio servidor não deixa você em conformidade com a LGPD sozinho. Veja onde os dados ficam, o que a ANPD exige e como configurar retenção, chave e transferência internacional.
Ler →
Webhook
Entenda o que é webhook, como funciona na prática e como usar no n8n e Make para criar automações em tempo real sem precisar saber programar.
Ler →
Como integrar o n8n com a OpenAI (ChatGPT): guia prático 2026
Guia direto para conectar o n8n à OpenAI: gerar a API key, configurar a credencial, escolher o modelo certo e montar o primeiro fluxo com ChatGPT. Com custos reais e erros comuns.
Ler →
Os 8 erros mais comuns no n8n para iniciantes (e como resolver cada um)
Nó desconectado, credencial expirada, Invalid JSON, workflow que trava na primeira falha. Veja os 8 erros que mais derrubam iniciantes no n8n e o passo a passo para resolver cada um.
Ler →