"Firebase vs Supabase: qual escolhi pro OverAir e por quê"

Toda semana alguém posta no Reddit ou no Twitter a mesma pergunta: "Firebase ou Supabase pra meu próximo projeto?" E toda semana os mesmos argumentos genéricos aparecem: "Supabase é open source", "Firebase tem lock-in", "Postgres é melhor que NoSQL".

Nenhum desses argumentos me ajudou quando precisei decidir o backend do OverAir — um SaaS de memória digital que roda via WhatsApp, processa áudio e imagem com IA, e dispara lembretes proativos pros usuários.

Escolhi Firebase. Firestore + Cloud Functions + FCM. Desde o primeiro commit. E se começasse hoje, faria a mesma escolha.

Vou explicar por quê — sem evangelismo, com os tradeoffs reais.

O critério que definiu tudo: triggers reativos no banco

O OverAir funciona assim: o usuário manda uma mensagem no WhatsApp, o webhook da Meta escreve um documento no Firestore, e uma Cloud Function dispara automaticamente via onCreate. Essa function processa a mensagem com Gemini 2.5 Flash, grava o resultado, e outra function reage ao onUpdate pra enviar a resposta via WhatsApp.

Esse pipeline é 100% event-driven. Não tem polling. Não tem cron verificando "tem mensagem nova?". Cada etapa é uma reação a uma escrita no banco.

No Firebase, isso é nativo. Você declara functions.firestore.document('messages/{id}').onCreate(...) e pronto. Sem infraestrutura extra, sem fila, sem worker.

No Supabase, o equivalente seria usar Database Webhooks — que usam pg_net pra chamar uma Edge Function via HTTP quando uma row é inserida. Funciona? Sim. Mas é uma camada extra: o trigger Postgres chama pg_net, que faz um HTTP POST pra Edge Function, que precisa estar deployada e respondendo. No Firebase, o trigger é direto — a function é o handler do evento, sem intermediário HTTP.

Pra um pipeline onde cada mensagem passa por 2-3 estágios reativos (receber → processar → responder → agendar lembrete), a simplicidade do Firestore trigger fez diferença real no tempo de desenvolvimento.

Push notifications: FCM é imbatível no Flutter

O OverAir tem um app Flutter que mostra o histórico de memórias e envia push notifications de lembretes. Firebase Cloud Messaging se integra com Flutter em literalmente 3 linhas de configuração — o plugin firebase_messaging resolve tudo: token management, foreground/background handling, tópicos.

Supabase não tem push notification service próprio. Você precisaria integrar OneSignal, Amazon SNS, ou Pusher Beams — cada um com seu SDK, seu dashboard, sua conta. Não é impossível, mas é mais uma peça móvel num sistema que já tem bastante coisa girando.

Pra um dev solo construindo dois SaaS ao mesmo tempo (OverAir e Studio Kallos), cada integração que eu evito é tempo que ganho.

Custo: Spark free tier segura o jogo

Firebase tem dois planos: Spark (grátis) e Blaze (pay-as-you-go). O Spark inclui:

Recurso	Limite gratuito/dia
Firestore reads	50.000/dia
Firestore writes	20.000/dia
Cloud Functions	2M invocações/mês
Auth	50.000 MAU
Hosting	10 GB armazenamento

O OverAir hoje, com zero clientes pagantes e só eu testando, consome uma fração disso. Mas mesmo com 500 clientes ativos, cada um fazendo 20 mensagens/dia, estamos falando de ~10.000 writes/dia e ~30.000 reads/dia. Ainda dentro do free tier.

Supabase também tem free tier generoso: 500 MB de storage, 50.000 MAU, API requests ilimitados. Mas o free tier do Supabase pausa o projeto depois de 7 dias sem atividade e limita a 2 projetos. O Firebase Spark não pausa nada — seu projeto fica no ar indefinidamente.

Quando você está em fase de validação e pode passar uma semana sem mexer no projeto enquanto resolve outra coisa, ter o banco pausado automaticamente é um risco real.

O Pro do Supabase custa US$ 25/mês por projeto. O Blaze do Firebase cobra por uso — e na escala do OverAir, esse uso dá centavos. A diferença é que no Supabase você tem um piso fixo; no Firebase, o piso é zero.

O tradeoff real: pricing por operação

A desvantagem mais concreta do Firebase é o modelo de cobrança do Firestore: por read/write/delete, não por query ou por GB transferido. Uma query que retorna 500 documentos conta como 500 reads. Se você não estruturar seus dados pensando nisso, a conta surpreende.

No Supabase (Postgres), você paga por storage e egress — não por quantidade de queries. Pra aplicações com queries complexas, joins pesados, ou dashboards analíticos, Postgres é objetivamente mais barato em escala.

Mas o OverAir não é uma aplicação analítica. Cada mensagem gera 3-5 writes e 5-10 reads. O padrão é previsível, o volume é baixo por operação. Firestore funciona bem pra esse perfil.

Se eu estivesse construindo um dashboard de métricas ou um CRM com relatórios complexos, Supabase seria a escolha óbvia.

Quando eu escolheria Supabase

Não é que Supabase seja ruim — é que ele resolve problemas diferentes melhor:

Projeto Postgres-first com queries SQL complexas, joins, views materializadas
Stack web moderno (Next.js, Nuxt, SvelteKit) onde o Supabase client brilha
Dados relacionais densos onde denormalizar pro Firestore seria dor de cabeça
Controle total sobre o banco — self-host, migrations, pg_dump

O Supabase em 2026 tem mais de 1.2 milhão de desenvolvedores ativos e empresas como Mozilla e Vercel usando em produção. Não é underdog — é uma plataforma madura.

A decisão resumida

Critério	Firebase	Supabase
Triggers reativos no banco	Nativo (onCreate/onUpdate)	Via Database Webhooks + HTTP
Push notifications (Flutter)	FCM integrado	Precisa de serviço externo
Free tier sem pausa	Sim	Pausa após 7 dias de inatividade
Pricing em baixa escala	Por operação (centavos)	US$ 0 free / US$ 25/mês Pro
Queries complexas/SQL	Limitado (NoSQL)	Postgres completo
Open source / self-host	Não	Sim
Lock-in	Alto (vendor Google)	Baixo (Postgres portável)

Pro OverAir — event-driven, mobile-first, Flutter, baixa escala — Firebase foi a escolha pragmática. Se o produto escalar pra milhares de clientes e as reads do Firestore começarem a pesar, migrar será trabalho. Mas esse é problema bom de ter.

Próximo post

Quarta sai o post pesado: "Quanto tempo leva pra construir um SaaS WhatsApp com IA do zero" — com timeline real do OverAir, fase por fase, incluindo os 40% do tempo que gastei em edge cases de áudio que ninguém avisa. Feed RSS pra não perder.

Fontes: