Quando uma IA monta um site, Supabase costuma aparecer logo entre as sugestões. Antes de conectar outra plataforma, eu pergunto o que o site vai precisar guardar depois de publicado. Um blog atualizado junto com o código tem uma resposta; um SaaS com contas, arquivos e dados de cada cliente tem outra.
Por que Supabase aparece em tantos projetos
Supabase reúne Postgres, autenticação, armazenamento e funções de servidor. Integrações prontas em hospedagens e ferramentas de criação tornam fácil ligar tudo a um projeto; muitos tutoriais seguem o mesmo caminho. Esse atalho ajuda quem realmente precisa das peças do Supabase e também faz a plataforma aparecer em projetos bem menores.
Eu separo essas situações pelo comportamento do site. Se ninguém cria conta e o conteúdo muda apenas quando publico uma nova versão, já tenho uma boa pista de que posso começar sem banco. Se cada pessoa salva informações próprias ou usa uma área de membros, aí preciso desenhar onde os dados ficam e quem pode acessá-los.
Um blog pode funcionar com arquivos Markdown
Uma landing page sem login pode ser entregue como HTML, CSS, JavaScript e imagens. Num blog, os artigos podem ficar em arquivos Markdown no repositório; o gerador do site os transforma em páginas, e o Git guarda o histórico. Publicar milhares de páginas de conteúdo não obriga, por si só, a adicionar um banco de dados.
Um banco começa a fazer sentido quando o site precisa consultar ou alterar dados durante o uso: por exemplo, quando visitantes enviam conteúdo, várias pessoas editam pelo painel ou cada usuário precisa ver registros próprios. Há também um cuidado de hospedagem: um arquivo SQLite local precisa de armazenamento persistente e gravável. Num ambiente serverless, D1 ou outro banco gerenciado costuma ser o lugar adequado para esses dados.
D1 encaixa bem quando o site já roda na Cloudflare
D1 é o banco SQL da Cloudflare baseado em SQLite. No Worker, eu o conecto por um binding configurado para o projeto. O código do servidor recebe o banco pelo ambiente e faz as consultas sem colocar uma credencial de conexão no navegador. Se uma rota do Worker permite alterar dados, ela ainda precisa verificar quem pode chamar aquela operação; o binding resolve a conexão, e a aplicação continua responsável pelas permissões.
No meu painel, quando gravei esse exemplo, havia 35 bancos, mais de 1 GB armazenado e cerca de 1,45 milhão de linhas. Eu administrava mais de 50 sites nesse ecossistema. Esses números mostram como organizo meus projetos; não são um limite de capacidade para copiar nem uma previsão de custo para outra conta.
O painel mostra tabelas, consultas e métricas como linhas lidas e gravadas. Quando uma consulta percorre mais dados do que eu esperava, consigo investigar e revisar o SQL ou um índice. Para quem já usou phpMyAdmin no WordPress, explorar tabelas e executar SQL no navegador é um fluxo familiar; eu também posso conferir uma consulta sugerida pela IA antes de aplicar mudanças.
Compare a conta inteira e mantenha uma cópia fora do banco
Na minha conta, o conjunto de sites e serviços Cloudflare me custava aproximadamente US$ 5 por mês na época do teste. Hoje, Workers Paid começa em US$ 5 por conta, enquanto D1 acompanha linhas lidas, linhas gravadas e armazenamento acima das cotas incluídas; R2 e outros produtos também têm suas próprias regras de cobrança. No Supabase, o Pro começa em US$ 25 por mês e inclui crédito de computação, além de Postgres, autenticação, armazenamento e funções. Compare o que você vai usar em cada plano, não apenas os dois valores de entrada.
D1 inclui Time Travel: posso restaurar o banco a um ponto dos últimos 30 dias no Workers Paid e 7 dias no Free. O recurso é automático e útil para desfazer uma migração ou uma consulta que alterou dados por engano. A restauração substitui o estado atual do banco, então eu também guardaria uma exportação em outro local para manter uma cópia fora dessa janela.
SQLite favorece leitura; pense no ritmo das gravações
SQLite fica embutido na aplicação e evita montar um servidor de banco separado. Ele funciona muito bem em projetos com bastante leitura e gravações ocasionais, como um site de conteúdo. O limite que muda a conversa é a escrita: cada banco D1 processa uma consulta por vez e pode enfileirar pedidos concorrentes. Se as consultas forem curtas e as gravações esparsas, isso costuma caber no uso de um site pequeno; um produto com muitas pessoas salvando informações ao mesmo tempo precisa de uma análise de capacidade mais séria.
A replicação de leitura do D1 pode distribuir consultas de leitura por outras regiões. Ela exige o uso da Sessions API, e as gravações continuam indo para a instância principal. Portanto, ajuda a atender mais leitores e reduzir a latência, mas não transforma o banco numa solução de escrita concorrente ilimitada.
Quando Supabase é a opção mais conveniente
Eu escolheria Supabase quando um produto precisa de Postgres e o pacote integrado economiza trabalho: autenticação pública, login social, arquivos, atualizações em tempo real ou funções de servidor. Também consideraria uma arquitetura de banco diferente se muitas pessoas precisassem gravar ao mesmo tempo. O valor está nos recursos que o produto vai usar, não na quantidade de serviços que o painel oferece.
Chave publicável e chave secreta têm papéis diferentes. A publishable key pode ficar no front-end quando as tabelas usam Row Level Security e políticas de acesso corretas. A secret key ignora essas proteções e deve ficar no servidor. Em Cloudflare, eu uso Access para restringir ferramentas internas à equipe; para clientes criarem contas e acessarem os próprios dados, preciso de autenticação e autorização dentro do aplicativo.
Minha escolha começa pelo tipo de dado: se o conteúdo só muda quando publico, guardo em Markdown e publico o site. Se preciso de dados dinâmicos e já trabalho nos Workers, começo avaliando D1. Se o produto pede contas públicas, recursos integrados do Supabase ou um volume de escrita que pede Postgres, uso Supabase. Assim escolho o banco pelo trabalho que ele vai fazer.