Por que o site da HTF não usa banco de dados
Em resumo: Conteúdo versionado em Git e HTML gerado no build entregam SEO melhor, custo zero e histórico de alterações. O preço são 40 segundos entre publicar e ver no ar.
Quando começamos o site institucional da Hack Tech Farm, a primeira proposta de arquitetura incluía Postgres, um servidor Express e um painel administrativo conversando com o banco em tempo real. Descartamos tudo isso. O site hoje não tem banco de dados, e a decisão melhorou três coisas ao mesmo tempo.
O que o buscador realmente lê
Existe uma confusão comum: a de que o banco de dados alimenta o Google. Não alimenta. Nenhum crawler tem acesso ao seu Postgres. O que o Google, o ChatGPT e a Perplexity fazem é uma requisição HTTP no domínio e a leitura do HTML que volta.
Isso significa que a pergunta certa não é onde o conteúdo está guardado, mas em que estado ele chega ao crawler.
Um site que busca dados de um banco pelo navegador entrega HTML vazio e preenche depois com JavaScript. Muitos crawlers não executam JavaScript. Um site que gera HTML no momento do build entrega o conteúdo pronto na primeira resposta.
Como funciona na prática
O catálogo de produtos vive num arquivo JSON versionado no repositório. Quando alguém publica pelo painel, uma função serverless grava o arquivo pela API do GitHub. O commit dispara um build, que reescreve as páginas HTML com o conteúdo novo.
| Aspecto | Com banco | Sem banco |
|---|---|---|
| Tempo até refletir | imediato | cerca de 40 segundos |
| Custo mensal | plano do provedor | zero |
| Histórico de alterações | precisa configurar | cada commit é uma versão |
| Se o serviço cair | site perde o conteúdo | site continua no ar |
O que isso custa
Quarenta segundos entre salvar e ver no ar. Para conteúdo institucional que muda uma vez por mês, é irrelevante. Para um painel de dados atualizado a cada minuto, seria inviável.
A pergunta que decide não é "banco é melhor que arquivo", e sim "com que frequência isso muda e quem precisa ver a mudança na hora".
Onde a decisão deixaria de valer
Três situações mudariam nossa escolha:
- Dados por visitante. Conta de usuário, carrinho, histórico pessoal. Nada disso cabe num arquivo versionado.
- Volume alto. Um catálogo com milhares de itens vira um JSON que o build precisa ler inteiro a cada deploy.
- Consulta analítica. Séries temporais e agregações são trabalho de SQL. Filtrar isso na memória é reimplementar um banco pior.
Nenhuma delas se aplica a um site institucional com quatro produtos no ar. Por isso a arquitetura mais simples também é, aqui, a mais rápida e a mais barata.