Branching do Supabase não é backup. Ele só anda para a frente.

Você ligou o branching do Supabase porque parecia o jeito caprichado de trabalhar. Agora existe um branch de preview ao lado do seu projeto, as mudanças são testadas ali antes de alguém ver, e a coisa toda parece bem mais segura do que no mês passado.

E é mais segura mesmo. Só que não é backup, e a diferença aparece em exatamente um dia.

Aqui está a parte que os guias de branching pulam: um branch é um segundo banco de dados ao lado do primeiro, e não uma versão anterior dele. O branching é o lugar aonde você vai antes de fazer uma mudança. Um backup é o lugar aonde você vai depois que alguma coisa já deu errado. Ligar o branching não deixa uma cópia dos seus dados em lugar nenhum.

O branching do Supabase é um backup?

Não. Um branch começa como um banco vazio vestido com o seu esquema, e nada no branching devolve uma versão anterior dos seus dados.

A própria documentação do Supabase é direta: "Branches novos não começam com nenhum dado do seu projeto principal. Isso serve para proteger melhor os seus dados sensíveis de produção". Um branch é construído a partir das suas migrações, e uma migração descreve o formato de um banco de dados. As tabelas, as colunas, as policies. Nunca as linhas.

Então o branch que está ao lado do seu projeto não é a cópia de terça. É um banco novo que nunca viu os seus usuários.

Se você nunca estabeleceu o que realmente está copiando o seu banco, essa é justamente a tarefa para a qual este artigo quer te mandar, e o seu plano resolve quase tudo em dois minutos.

O que um branch é de verdade

Um segundo projeto Supabase inteiro, com tudo dele próprio.

"Cada branch é um ambiente separado com a própria instância do Supabase e as próprias credenciais de API", é assim que a documentação coloca. String de conexão própria, chaves próprias, Storage próprio, contas de login próprias, linhas próprias. Nada lá dentro está ligado ao projeto em que os seus usuários estão, e é exatamente isso que torna seguro quebrar coisas ali.

Esse isolamento é a funcionalidade inteira, e é também por isso que ele não consegue servir de backup. A cópia dos seus dados que você esperava nunca foi tirada, e o lugar onde você iria procurar por ela está vazio desde o dia em que foi criado.

O que um merge faz, e o que ele não faz

Ele leva as suas mudanças de esquema para a produção. Ele nunca leva linhas, em nenhuma direção, em nenhum momento.

Quando você faz merge, o Supabase aplica as migrações do seu branch no seu banco de produção e publica as suas mudanças de Edge Functions. Essa é a carga inteira. Uma tabela nova, uma coluna nova, uma policy reescrita: essas viajam. As linhas que você criou testando ficam no branch, e as linhas da produção ficam exatamente como estavam, inclusive aquelas que você esperava substituir.

As pessoas esperam uma versão disso que não existe: um merge que entra na produção e coloca as coisas de volta como estavam. O que o branching tem no lugar é um deploy, aplicado para a frente, em cima do que estiver na produção naquele momento.

Mas eu cloneei meus dados de produção para o branch

Então você tem uma cópia das suas linhas, e três coisas sobre essa cópia decidem quanto ela vale no dia em que você precisar dela.

Dá para fazer isso e não é nada obscuro. A CLI do Supabase descreve a opção como clonar os dados de produção para o banco do branch, e a API de management aceita a mesma opção quando cria um branch. Se você usou, o seu branch guarda os seus dados mesmo.

• Ela foi tirada uma vez. O clone acontece na criação do branch e nada completa ele depois. Cada pedido, cada cadastro e cada comentário desde então vive na produção e em nenhum outro lugar, e é toda essa a diferença entre uma cópia e um calendário.
• Ela está dentro da mesma conta. Um branch é outro projeto sob a mesma organização, no mesmo cartão, atrás do mesmo login. Todo jeito de perder a sua conta do Supabase leva o branch junto, e esse é um desastre diferente de estragar os próprios dados.
• Ninguém leu ela de volta. Um clone que parou no meio é idêntico por fora a um que terminou, até o momento em que você abre.

O branch é a parte feita para desaparecer

Um branch de preview é apagado quando o pull request dele é mergeado ou fechado. Esse é o comportamento documentado do recurso.

O Supabase chama os branches de preview de "efêmeros e mais adequados a testes focados" e diz que eles "são apagados automaticamente quando um PR é mergeado ou fechado". O outro tipo, os branches persistentes, são "de vida longa e recomendados para ambientes como staging, QA ou desenvolvimento", e esses sobrevivem ao fechamento do pull request.

Então, no ajuste padrão, o branch que guarda a sua única cópia clonada é justamente o que o seu fluxo de trabalho joga fora no dia em que o trabalho termina. Mantê-lo significa deixá-lo persistente, e um branch persistente é um segundo projeto Supabase ligado. O Supabase oferece branching nos planos pagos e cobra por branch e por hora, na página de preços deles.

Para que o branching serve de verdade

Para bastante coisa, e este artigo seria desonesto se não dissesse isso.

Um branch é o lugar mais barato que existe para descobrir que uma migração apaga uma coluna, antes que ela apague a coluna em que os seus clientes estão sentados. Ele deixa você ensaiar uma mudança de policy contra um banco com o mesmo formato do seu, com chaves próprias, de modo que um erro não alcança ninguém. Ele dá a uma IA um lugar para estar errada que não é o seu app em produção. Um backup não faz nada disso.

O buraco está em que tipo de acidente ele cobre. O branching protege as mudanças que passam por um pull request. A maior parte do que de fato custa os dados das pessoas nunca chega perto de um: um delete no editor de tabelas do Supabase que pegou mais linhas do que a intenção, um script de seed apontado para o projeto de produção, uma migração que uma IA escreveu e você aprovou à uma da manhã, uma faxina no que parecia dado de teste. Nenhum desses passa por um branch a caminho da produção, que é o mesmo motivo pelo qual voltar o código não traz de volta uma tabela apagada.

Esse segundo tipo de acidente é o que um backup responde. Ele fica atrás de você no tempo, guardando o estado do seu banco num momento que você consegue nomear, para que um erro cometido fora do seu fluxo de trabalho ainda tenha para onde voltar.

É isso também que o Reeve Care é: cópias programadas do seu banco de dados Supabase, guardadas fora da sua conta do Supabase, lidas de volta e conferidas antes de qualquer uma contar como feita. Conecte seus buckets de Storage e os arquivos que os seus usuários subiram vão junto, então uma restauração devolve as linhas e as imagens para as quais essas linhas apontam.

Deixe o branching ligado de qualquer jeito. Nada acima é argumento para desligá-lo.

O que fazer esta semana

Antes de fechar esta aba, abra o seu projeto no Supabase e veja se alguma coisa está tirando uma cópia num calendário. Essa única resposta é o trabalho inteiro de hoje, e o branching não muda isso em nenhum sentido. A checklist de segurança de 10 minutos cobre isso junto com o resto do que vale confirmar num app recém-lançado, e o que uma cópia contém e o que o botão de restaurar faz de verdade está detalhado na página de backups do Supabase.