Você não precisa do Supabase: quando o D1 (ou nem banco) já resolve

Por que todo tutorial de vibe coding empurra o Supabase

O Supabase ficou famoso principalmente entre quem publica de graça na Vercel. A Vercel não oferece banco de dados nativo. Você sobe o front, e na hora de guardar usuário, post ou sessão, aparece o vazio. O Supabase entra exatamente aí: Postgres, autenticador, storage. Plataformas como Vercel, Netlify, Lovable e outras de vibe coding já vêm com um botão de conectar ao Supabase. Não é caridade. O Supabase é um serviço de assinatura. O plano gratuito é generoso, mas o pago, na época desta gravação, começava na casa dos US$ 25 no Pro — mais caro que o plano de Workers que eu pago na Cloudflare. Alguém ganha comissão nessa indicação. Você acha mesmo que o botão de conectar de graça existe por nada?

Outro motivo da popularidade: a maior parte de quem grava vibe coding não conhece as opções. Replica o que aprendeu. Não olha a necessidade real do site. Eu vejo isso o tempo todo. O guru montou um clone de Twitter no tutorial, então o seu blog de receitas herda Postgres, Row Level Security e Auth. A ferramenta certa para o clone não é a ferramenta certa para a landing.

O que o Supabase acerta — e o que a maioria das pessoas não está construindo

Não entenda errado. O Supabase é uma ótima opção quando o assunto é PostgreSQL de verdade: SaaS robusto, muita escrita no banco, milhares de usuários logados ao mesmo tempo. Auth nativo, storage, Edge Functions. É um back-end completo. Se você está construindo isso, use. Eu não vou te puxar para o SQLite por birra.

Essa não é a realidade da maioria. Quem cria site com vibe coding quer, na prática, uma landing page. Ou no máximo um blog. Usar Supabase nesse recorte é desnecessário, custoso e até perigoso: você passa a ter chave, URL de API, regra de acesso e um segundo painel para um projeto que poderia ser HTML, um Worker e, se precisar de artigo, um arquivo Markdown no repositório. O plano gratuito aguenta o começo. Quando você começa a pagar — igual na Vercel — prepare-se para o rombo de uso, de projeto ativo e de recurso que o tutorial não mostrou na thumbnail.

Landing e blog: quando você nem precisa de banco

Se o site não tem login, não tem painel de usuário e não tem dado que muda a cada visita, você não precisa de banco. Página, artigo e dado estático cabem em Markdown. A IA gera o arquivo, o Worker ou o gerador estático lê na build ou na requisição, e o Git vira o histórico. Sem Postgres. Sem migration. Sem chave no cliente.

Mesmo o caso que parece “grande” — blog com milhares de artigos ricos, site em vários idiomas — ainda não pede Supabase só por volume. Volume de leitura é o cenário em que o SQLite se sai bem. O que o Supabase resolve de verdade é escrita concorrente e conta de usuário, não a quantidade de páginas. Tratar “muita página” como “preciso de Postgres gerenciado” é o atalho que o tutorial vende. Não é o desenho.

Dois serviços, custo em dobro — e o D1 no mesmo lugar do site

Usar Supabase com Vercel (ou com qualquer front separado) é viver em dois serviços: a hospedagem e o banco. Cada um com painel, fatura, chave e falha própria. Isso dobra o custo e a integração. É aqui que, na minha opinião, entra um dos melhores ecossistemas serverless: a Cloudflare. Assim como a Vercel, dá para começar de graça. A diferença é o banco: o D1, um SQLite gerenciado, conecta nativamente no Worker. Sem URL pública obrigatória. Sem chave de API no front. Binding: você associa o banco ao Worker por um nome, e o código fala com `env.DB`. Acabou o vazamento clássico de `SUPABASE_ANON_KEY` no repositório.

Na época da gravação eu pagava cerca de US$ 5 por mês no plano pago da Cloudflare — Workers, CDN, R2, D1, o pacote. Tenho mais de 50 sites. Se você tem um ou dez, talvez nem precise desse plano. No painel do D1 eu mostrei cerca de 35 bancos, mais de 1 GB armazenado, mais de 1,45 milhão de linhas. Isso não me custa um Postgres em cada projeto. Custa o plano e a cota de leitura e escrita. No Free, a Cloudflare inclui 5 milhões de linhas lidas por dia, 100 mil escritas por dia e 5 GB no total. No Paid, a cota mensal sobe para 25 bilhões de leituras e 50 milhões de escritas, com 5 GB inclusos e o excedente cobrado. Confira a tabela oficial antes de prometer “grátis para sempre” a um cliente: cota muda, e consulta sem índice conta linha lida, não linha devolvida.

O que o painel do D1 mostra na prática

O D1 não é um arquivo `.db` solto na pasta do site. É o SQLite da Cloudflare, com métrica, console e restauração. Você abre o banco e vê tabelas, como no MySQL, no MariaDB ou no Postgres. Número de linhas lidas, gravadas, total de consultas, detalhe de request, localização. Se uma consulta está varrendo tabela demais, aparece. Aí você senta com a IA e cria índice, em vez de “otimizar no escuro”.

No console você roda SQL como se fosse um terminal. Time Travel — viagem no tempo — restaura o banco a qualquer minuto. Nos bancos de produção, a janela é de 30 dias no plano pago e de 7 dias no Free. Não precisa ligar backup: o Time Travel já está ligado, sem custo extra de histórico. Restore é destrutivo: sobrescreve o banco no lugar. Anote o bookmark anterior se quiser desfazer. Mesmo assim eu ainda guardo cópia em outro lugar. Vai que a Cloudflare apaga tudo. Redundância chata é redundância que te salva.

Dá para ligar réplica de leitura e espalhar consulta perto do visitante. O explorador de tabelas é o phpMyAdmin que quem veio do WordPress conhece, só que moderno: altera no navegador, solta o `SELECT`, exporta CSV ou SQL. Não é o painel do Supabase. É o suficiente para ver o que o site está guardando sem abrir cliente gráfico.

1. No dashboard da Cloudflare, abra Computação → D1 e escolha o banco do site — não um banco “de teste” misturado com produção.
2. Olhe métrica de linhas lidas e gravadas antes de sair criando índice: consulta lenta quase sempre é scan sem filtro.
3. No console, rode o `SELECT` que a página usa e confira se o `meta` de linhas lidas faz sentido para o volume do artigo.
4. Teste Time Travel num banco descartável: `wrangler d1 time-travel info` e restore por bookmark. Produção só depois que você entendeu que o restore sobrescreve.
5. Exporte um recorte (CSV ou SQL) para um bucket ou disco seu. Os 30 dias do Time Travel não substituem arquivo fora da conta.
6. No Worker, associe o banco por binding (o nome em `wrangler.jsonc` / `wrangler.toml`), não por URL e chave no cliente.

SQLite é um arquivo — e o “lite” no nome engana

Mesmo que você não queira o ecossistema Cloudflare, o SQLite roda em quase qualquer hospedagem. É um arquivo `.db`. Pode ficar na raiz do projeto, no disco do servidor, no celular, no navegador, num Raspberry Pi. Apesar do “lite” no nome, aguenta milhões de linhas sem drama. Eu já estava acima de 1,45 milhão só no recorte que mostrei. A diferença para MySQL, MariaDB e Postgres é que o SQLite é embutido no processo. Não tem servidor de banco. Não tem TCP. Não tem autenticação de rede. Não tem pool de conexão. Por isso a leitura é rápida: não atravessa a sala para pedir um SELECT.

A desvantagem cabe em uma frase: milhares de leituras simultâneas, uma escrita por vez. Cem pessoas clicando em “salvar” ao mesmo tempo viram fila. Na maioria dos sites isso é raro. Comentário de blog, formulário, painel com um editor só — uma escrita por segundo já resolve, e a própria aplicação (ou a Cloudflare, no D1) enfileira. O SQLite também não é o rei da escala horizontal clássica. A Cloudflare lançou réplica de leitura justamente para o lado que o arquivo sozinho não cobre. Dez milhões de visitas no dia, no recorte que eu defendo, é leitura. Escrita concorrente de marketplace é outro problema.

Quando você realmente precisa do Supabase

Você precisa do Postgres do Supabase quando o produto é rede social, marketplace, sistema financeiro, ou uma aplicação com centenas de pessoas editando o mesmo dado ao mesmo tempo. Aí a fila de uma escrita do SQLite deixa de ser detalhe. A Cloudflare também tem caminho para carga maior — o próprio D1 com réplica, Durable Objects, ou outro banco fora — mas eu não vou fingir que o D1 é o substituto universal do Postgres.

O diferencial que eu não tinha falado ainda: Supabase Auth. Login de usuário, membro, sessão, provedor social, Row Level Security. Se o produto é área logada para o público, isso pesa. Storage e Edge Functions fecham o pacote: o Supabase vira o back-end. O D1 é banco. O Worker é o back. O Access da Cloudflare protege o painel interno — domínio, rota, gente da equipe — e no plano gratuito do Zero Trust a cota é rígida: 50 usuários. Não é auth de SaaS. Não deixe o visitante “criar conta” no Access e chamar isso de área de membros. Eu já gravei a proteção de site feito com IA; o Access entra como cadeado do admin, não como clone do Supabase Auth.

Resumo honesto: blog, site com login simples em que o usuário só aciona uma ferramenta ou manda um texto para a IA, site multilíngue, API e banco no mesmo Worker — o Supabase só aumenta custo e quebra o sistema único. Se você está criando com IA e vibe coding, eu fico com a Cloudflare: hospedar na borda e guardar no D1. Tamanho certo não é xingamento ao Postgres. É recusar o botão de conectar porque o tutorial tinha um.

• Rede social, marketplace ou sistema financeiro com muita escrita simultânea
• Centenas de pessoas editando o mesmo registro ao mesmo tempo
• Auth público de membros, com provedor social e regra por linha
• Storage e função de borda que você não quer construir no Worker
• Equipe que já vive no painel do Supabase e não quer outro desenho

Na sequência

1. Liste o que o site guarda hoje: artigo, lead, sessão de usuário ou nada.
2. Se não há login público nem escrita concorrente, teste Markdown ou um SQLite/D1 antes do Postgres.
3. Some a fatura de hospedagem com a do banco: dois serviços só compensam se cada um estiver fazendo um trabalho que o outro não faz.
4. No Worker, use binding. Chave de API no front é o caminho clássico de vazamento.
5. Ligue a métrica de linhas lidas no D1 e crie índice onde o scan aparecer.
6. Trate Time Travel como janela (30 dias no Paid, 7 no Free) e mantenha export fora da conta.
7. Não use Cloudflare Access como login de cliente: o limite de assentos existe e o produto é outro.

Onde isso quebra