Supabase e Firebase resolvem o mesmo problema — um backend (banco, auth, storage, APIs) sem rodar servidores — mas apostam no oposto. Firebase é o incumbente maduro, proprietário e NoSQL; Supabase é o desafiante open-source e SQL.
Frente a frente
| Supabase | Firebase | |
|---|---|---|
| Banco de dados | PostgreSQL (SQL, relacional) | Firestore (NoSQL, documentos) |
| Open source | Sim — self-hostável | Não — proprietário (Google) |
| Lock-in | Baixo (Postgres padrão) | Maior (ecossistema Google) |
| Realtime | Sim | Sim — uma força central |
| Ideal para | Dados relacionais, times SQL | Mobile, dados flexíveis, stack Google |
Escolha Supabase se…
- Seus dados são relacionais e você quer SQL real e joins.
- Valoriza open source e a opção de self-host.
- Gosta de aplicar acesso no banco com RLS.
Escolha Firebase se…
- Constrói mobile-first e quer SDKs de primeira linha.
- Seus dados são documentos e quer sync em tempo real.
- Já está no Google Cloud.
Preço e o footgun de segurança
Ambos têm free tier e preço por uso (veja preços do Supabase). E compartilham uma armadilha: o cliente fala com o banco direto, então suas regras são a única coisa que protege os dados. No Supabase é RLS; no Firebase, Security Rules. Publique-os mal e seus dados ficam públicos. Um scan grátis do Nurbak confirma que suas regras protegem antes de lançar.