Domingo, 15h20. O login da aplicação falha porque o Auth não alcança o PostgreSQL. Numa instalação self-hosted do Supabase, o profissional responsável precisa abrir os logs, descobrir qual componente parou e restaurar o acesso dentro do prazo combinado com os clientes.

Essa é uma hipótese de manutenção, não um caso que estou apresentando como vivido. Eu a uso porque a comparação entre Supabase Cloud e self-hosted fica incompleta quando considera apenas assinatura e servidor. A hora disponível para investigar, atualizar e recuperar também custa.

Direto ao ponto

Minha preferência é o Supabase Cloud quando a instalação própria não atende uma exigência específica. O serviço gerenciado mantém a plataforma, enquanto você continua responsável pelo schema, pelas queries e pelas permissões da aplicação. A cobrança varia com assinatura, compute e recursos adicionais.

Self-hosted faz sentido quando a infraestrutura precisa ficar numa rede ou localização determinada e existe capacidade técnica para mantê-la. Servidor, cópias externas, monitoramento, atualização e atendimento fora do horário comercial entram na mesma comparação.

Antes do incidente, existe uma rotina invisível

A documentação de self-hosting usa Docker para instalar os componentes na infraestrutura escolhida. O ambiente iniciado pela CLI durante o desenvolvimento não representa sozinho uma instalação pronta para tráfego público.

Os serviços evoluem em conjunto. Uma atualização precisa preservar a comunicação entre Auth, PostgreSQL, API e Storage. Voltar a imagem de um container não desfaz necessariamente uma migração aplicada ao banco, por isso o procedimento deve incluir compatibilidade de schema e sequência de retorno.

Mesmo sem indisponibilidade visível, o servidor recebe atualizações e os volumes crescem. Certificados também vencem. Abra o resultado da rotina de cópia e restaure um arquivo em outro ambiente, pois a execução agendada pode falhar durante semanas sem chegar ao cliente.

Esse trabalho fundamenta minha ressalva sobre instalar apenas para evitar uma mensalidade. O código aberto permite executar o Supabase em infraestrutura própria. Ele não fornece as horas nem o plantão necessários para manter essa instalação.

Às 15h25, o log precisa indicar onde procurar

O cliente informa que não consegue entrar. A primeira leitura separa falha no frontend, Auth indisponível e conexão recusada pelo PostgreSQL. Logs com horário e identificador permitem acompanhar a tentativa e comparar o relato recebido pelo suporte.

Se o disco estiver cheio, liberar espaço pode devolver gravações temporariamente. A correção completa inclui localizar o crescimento, preservar os arquivos necessários e impedir que a rotina de backup ocupe o mesmo volume até interrompê-lo novamente.

Se uma atualização incompatível atingiu o Auth, você precisa saber quais imagens estavam ativas e quais alterações chegaram ao banco. A recuperação usa registros técnicos preparados antes do domingo. Sem versão anotada e procedimento ensaiado, cada comando aumenta a incerteza.

Uma aplicação que aceita algumas horas parada permite outra resposta. Um produto pago com prazo curto exige disponibilidade, monitoramento e um profissional capaz de agir. O valor dessa capacidade pertence ao custo mensal do self-hosted.

Às 15h40, restaurar o banco ainda não devolve o contrato

O backup do PostgreSQL não inclui os objetos enviados pela API do Storage. Ele preserva metadados, mas o arquivo precisa de uma cópia própria, conforme a documentação de backups.

Um ensaio de recuperação deve abrir uma jornada, não terminar no comando do banco. Restaure o PostgreSQL num ambiente separado, recupere os objetos e faça login com um cliente de teste. Consulte o cadastro e abra o contrato ligado a ele.

O conjunto self-hosted padrão não traz o serviço de backups gerenciados nem o PITR (Point-in-Time Recovery) administrado do Cloud. Você pode construir retenção e recuperação próprias. Inclua armazenamento fora do servidor principal e tempo para testar cada etapa.

No Cloud, confira o que está habilitado no projeto. Plano pago, retenção e PITR possuem condições próprias. O nome da assinatura não substitui a leitura da configuração nem a recuperação dos arquivos do Storage.

A fatura do Cloud tem mais de uma linha

Na página de preços do Supabase, consultada em 7 de setembro de 2026, o plano Pro começa em US$ 25 mensais e inclui US$ 10 em créditos de compute. Esse valor não representa o preço final de toda aplicação. Consumo adicional, outro projeto e recursos contratados alteram a cobrança.

Cada projeto executa sua instância de banco dentro da estrutura administrativa do serviço. Um ambiente extra pode acrescentar compute mesmo com a assinatura ativa. Projete desenvolvimento, homologação e produção de acordo com o uso pretendido.

O Cloud mantém componentes da plataforma, mas não corrige uma query lenta. Antes de aumentar compute, abra o plano de execução, observe índices e confira quantas conexões o backend mantém. Revise também as policies de RLS e conserve a chave administrativa fora do navegador.

O artigo da Promovaweb sobre o backend do Supabase acompanha login, linha e arquivo pela aplicação. Essas responsabilidades permanecem com você nos dois formatos de hospedagem.

Calcule o self-hosted com horas observadas

Use uma atualização e uma restauração de teste para obter uma primeira medida. Registre preparação, execução, conferência e correção. Acrescente o acompanhamento das versões e a disponibilidade necessária para atender uma falha dentro do prazo prometido.

O servidor entra com CPU, memória, disco, rede e armazenamento externo para cópias. Uma instalação que precisa sobreviver à falha da máquina principal exige outra composição. O artigo sobre como escolher um provedor de VPS relaciona região, suporte e recuperação a essa escolha.

Compare essas horas com a fatura prevista do Cloud usando a mesma jornada e o mesmo compromisso de recuperação. Hospedagem própria pode custar menos em moeda e mais em atenção técnica. Serviço gerenciado pode custar mais em assinatura e liberar os desenvolvedores da manutenção da plataforma.

Quando a instalação própria se justifica

Uma rede isolada pode exigir que todos os componentes funcionem dentro da infraestrutura da empresa. Um contrato também pode determinar localização ou forma de acesso aos registros. Examine a exigência concreta antes de concluir que o Cloud não atende.

Capacidade existente muda a comparação. Uma empresa que já mantém PostgreSQL, containers, observabilidade e atendimento de incidentes consegue incorporar o Supabase à mesma rotina. Ainda precisa considerar os componentes adicionais e testar a recuperação completa.

Na minha avaliação, pagar pelo Cloud costuma compensar quando o principal objetivo é desenvolver a aplicação. A instalação própria se torna coerente quando oferece controle necessário e a empresa aceita o trabalho contínuo que acompanha esse controle.

A Formação DevOps da Promovaweb desenvolve a base para manter servidores e testar recuperação. Para acompanhar uma aplicação já publicada, o Conselheiro de Tecnologia da Dev Side Studio oferece uma segunda leitura recorrente sobre arquitetura, infraestrutura e deploy.

Volte ao domingo. Às 15h20, o cliente não entra. O formato escolhido vale a pena quando o custo previsto inclui o profissional responsável, os registros e o procedimento capazes de devolver login, cadastro e arquivo dentro do prazo combinado.