Read this guide in English

Como fazer backup do Supabase: todas as opções comparadas

Existem quatro respostas reais: os backups que o Supabase inclui, o add-on PITR, fazer você mesmo com pg_dump, e um serviço como o nosso. Cada uma cobre falhas diferentes, e duas lacunas atravessam quase todas. Este guia mostra o que cada opção realmente protege, com comandos que funcionam e preços de setembro de 2026.

O que o Supabase inclui: backups diários no Pro

No plano Pro (US$ 25/mês, em setembro de 2026) o Supabase faz um backup diário do seu banco e guarda por 7 dias. Você restaura pelo painel, no lugar. Três limites que precisam ficar claros:

• Só o banco de dados. Arquivos do Storage — uploads de usuários, avatares, documentos — não estão no backup.
• Geralmente não dá para baixar. Projetos ainda no processo de backup lógico antigo conseguem baixar backups pelo painel — mas projetos no Postgres 15.8.1.079 ou mais novo, e qualquer projeto com PITR ativado, usam backups físicos, que não podem ser baixados. No processo físico, ter uma cópia sua significa rodar pg_dump você mesmo — o guia de exportação em .sql tem os comandos exatos.
• Granularidade diária. Um deploy ruim às 17h pode custar tudo desde a noite anterior.

Para um projeto pessoal em que perder um dia é sobrevivível, isso é genuinamente suficiente. É o padrão por um motivo. No plano Free não há backups automáticos — aqui está o que isso significa na prática, e o que fazer a respeito.

Como baixar o seu backup do Supabase

A pergunta seguinte a “existe um backup diário” é sempre “posso ficar com ele?”, e a resposta depende de uma engrenagem que você não escolheu. Abra Database → Backups no painel. Se cada backup tem uma opção de download ao lado, seu projeto está no processo lógico antigo e você pode pegar o arquivo. Se não há opção de download, o projeto está em backups físicos — Postgres 15.8.1.079 ou mais novo, ou qualquer projeto com PITR — e esses restauram no lugar, mas não estão disponíveis para download direto; nenhuma configuração ou pedido ao suporte muda isso.

Ou seja: para a maioria dos projetos criados recentemente, baixar um backup do banco é na verdade fazer um — um dump lógico que você roda contra a string de conexão e que passa a ser inteiramente seu. É o comando pg_dump duas seções abaixo. O guia de exportação em .sql percorre a verificação no painel e o comando em detalhe.

Uma nuance para a implicação cair no lugar certo. Backups físicos não são um beco sem saída dentro do Supabase: em planos pagos, o painel consegue restaurar um deles em um projeto novo, usuários do Auth inclusos. O que eles não conseguem é sair — não existe arquivo para guardar, arquivar ou reproduzir em algum lugar que não seja o Supabase. Para uma cópia que sobreviva a um problema na conta ou mude de host, ela ainda tem que ser uma que você fez.

O add-on PITR: US$ 100/mês por projeto

O Point-in-Time Recovery custa US$ 100/mês por projeto para cada janela de retenção de 7 dias (em setembro de 2026). Em troca você ganha pontos de recuperação com precisão de segundos: volte o banco para 14:03:27, logo antes da migration ruim rodar. Se você precisa de RPO de minutos — um app em produção onde perder até uma hora de escritas é inaceitável — o PITR é a escolha certa, e nada mais neste guia o substitui.

Continua sendo só o banco de dados, continua vivendo na infraestrutura do Supabase, e o preço é por projeto — três projetos com PITR são US$ 300/mês. Escrevemos um comparativo honesto entre PITR e BackupDrill (em inglês), incluindo onde o PITR vence de lavada.

Faça você mesmo: pg_dump para um armazenamento seu

A resposta clássica, e boa se você a mantiver. Pegue a string de conexão do Session pooler no botão Connect no topo do painel. Não use a Direct connection — ela roda em IPv6, a menos que o projeto tenha o add-on pago de IPv4, e falha com erro de rede em redes só-IPv4, que é de longe a falha mais comum de backup faça-você-mesmo.

# String do Session pooler — botão Connect no topo do painel
export DB_URL="postgresql://postgres.<project-ref>:<senha>@aws-0-<regiao>.pooler.supabase.com:5432/postgres"

pg_dump "$DB_URL" \
  --format=custom \
  --schema=public \
  --file="backup-$(date +%F).dump"

Repare no --schema=public: isso captura só o schema da sua aplicação. Os schemas gerenciados pelo Supabase — auth (seus usuários), storage (metadados de arquivos) — não entram, e despejá-los sem ser superusuário é restrito. Saiba o que o seu backup contém e não contém antes de precisar dele.

Esse único comando é o caso de backup. Uma armadilha que vale conhecer se você preferir a CLI oficial: a saída padrão do supabase db dump contém nenhuma linha — só definições de schema. O guia de exportação em .sql cobre os dois comandos e essa armadilha em detalhe. Se o que você quer é uma exportação avulsa e não um backup — schema sem linhas, linhas sem schema, roles personalizadas, ou uma cópia destinada a outro projeto — as flags mudam para cada caso e o guia de exportação (em inglês) tem o conjunto completo de parâmetros e o caminho de clonagem para um projeto novo.

Duas coisas mordem as pessoas aqui:

• Diferença de versão. A versão major do seu pg_dump precisa ser ≥ a do servidor — o Supabase roda PG 15 ou 17. Compare pg_dump --version com select version(); um cliente mais antigo se recusa a despejar um servidor mais novo.
• Use o usuário postgres do pooler. Uma role somente-leitura comum dá erro em tabelas com RLS e perde grants de sequences, então o dump morre no meio ou restaura incompleto.

A conta de egress que ninguém menciona

Todo backup puxa seus dados para fora do Supabase, e isso é egress não cacheado: US$ 0,09/GB além da cota do plano (Free 5 GB, Pro 250 GB por mês; no Free o excedente aciona restrições de uso justo, nunca cobrança). O Spend Cap vem ligado por padrão no Pro: esgotada a cota, o egress seguinte é bloqueado até o próximo ciclo — o tráfego do seu app incluído, não só o do backup. Na prática: um backup semanal de um projeto de 10 GB é praticamente grátis; um backup diário de um projeto de 50 GB custa uns US$ 112/mês — mais que o PITR. Tamanho × frequência decide tudo; a documentação da CLI inclui um comando estimate que projeta o seu número antes de você agendar qualquer coisa.

E depois que o dump dá certo você ainda precisa agendá-lo — o guia de GitHub Actions (em inglês) percorre um workflow semanal completo — enviá-lo para um armazenamento que você controla (nosso guia de configuração de bucket cobre R2, S3 e B2), rotacionar cópias antigas e testar restaurações.

As duas lacunas em tudo acima

Lacuna um: arquivos do Storage. Uma restauração do banco — embutida, PITR ou pg_dump — só traz de volta a tabela storage.objects, que é metadado. Os arquivos de verdade vivem em um backend S3 separado, então o banco restaurado aponta para arquivos que podem não existir mais. Toda URL resolve em 404 enquanto toda query SQL parece saudável. Escrevemos a mecânica completa e a solução (em inglês).

Lacuna dois: verificação. Nenhuma dessas opções restaura o seu backup para conferir se ele funciona. Um backup que você nunca restaurou é um palpite — dumps feitos com a role errada, uma versão de pg_dump incompatível ou um job que falhou pela metade parecem sucesso até o dia em que você precisa deles. O teste é barato e nada aqui roda por você, então escrevemos como testar se o seu backup realmente restaura (em inglês) — à mão em quinze minutos, ou automatizado.

Onde o BackupDrill entra

O BackupDrill é construído em torno dessas duas lacunas. Ele faz backups agendados do banco e, depois que você adiciona as chaves S3 do Storage, dos seus arquivos do Storage, grava tudo no seu próprio bucket S3, R2 ou B2 — nunca no nosso — e depois roda ensaios de restauração automáticos na cadência do seu plano (semanal em todo plano pago; o Free ganha um ensaio no primeiro backup): o snapshot mais recente é restaurado em um Postgres descartável e verificado — sha256 do arquivo, pg_restore concluído, objetos post-data (índices, constraints, triggers) presentes, contagem de tabelas igual ao manifesto, nenhuma tabela faltando, tabelas com dados não vazias. Se um ensaio falha, você recebe um e-mail — antes de precisar do backup, não depois. Avaliando outros serviços hospedados? Comparamos SimpleBackups e BackupDrill (em inglês) com honestidade, incluindo onde eles vencem.

O plano gratuito cobre um projeto com backups semanais; os planos pagos custam US$ 19, US$ 49 e US$ 99 por mês (em setembro de 2026). O motor de backup em si é open source (MIT) em github.com/backupdrill/cli, então nada no formato prende você — restaurações funcionam com o pg_restore comum, com ou sem a gente. Comece pelo quickstart, ou leia primeiro o guia de restauração e recuperação se quiser ver o caminho do dia ruim antes de se comprometer.

Qual você deve escolher

Essas opções se combinam. PITR mais BackupDrill é uma configuração legítima: PITR para granularidade de recuperação, BackupDrill para cópias fora da plataforma, arquivos do Storage e prova de que as restaurações funcionam.

Perguntas frequentes