Ferramentas #11 — Firebase: onde ele entra (e por que Supabase cobre a maior parte)

Honestidade primeiro: nosso stack de dados é Supabase-first. Então este guia é sobre onde o Firebase faz sentido — e onde não precisa, porque já temos a peça.

O que é

Plataforma de backend-as-a-service do Google, com forte pegada mobile: Firestore (banco de documentos em tempo real), Realtime Database, Authentication, Cloud Messaging (FCM, push), Remote Config, A/B Testing, Crashlytics e Hosting.

Onde ele faz sentido pra gente

Push notifications (FCM) — caminho padrão pra push em mobile (e web push).
App mobile / realtime de cliente — app nativo que precisa de sync em tempo real e offline-first → Firestore brilha.
Crashlytics — crash reporting específico de mobile.
Remote Config / A/B — mudar comportamento do app sem republicar na store.

Onde Supabase já resolve (e não duplicamos)

Banco relacional → Postgres no Supabase (#03), com SQL de verdade e RLS.
Auth web → Supabase Auth com Google OAuth.
Erro web → Sentry (#10).

Conceitos-chave

Firestore é NoSQL (documentos) — modele por padrão de leitura, não normalizado como tabela.
Security Rules — o equivalente do RLS no Firebase; sem elas, dado aberto.
Custo por operação — você paga por leitura/escrita/documento; padrão de acesso ingênuo sai caro.

Boas práticas

Um dado, um dono. Não espelhe o mesmo dado em Firestore e Postgres — sincronização vira dor.
Security Rules tão a sério quanto RLS.
Modele pra leitura no Firestore (desnormalização consciente).

Pegadinhas

⚠️ Dois bancos = duas verdades. Misturar Firestore e Postgres pro mesmo dado gera drift e bug.
⚠️ NoSQL não é tabela — query relacional no Firestore dá problema.
⚠️ Custo escala com leitura — cuidado com listas grandes e polling.

Quando usar (e quando não)

Use pelos pontos fortes mobile/push/realtime. Não use pra substituir o Postgres/Supabase no que é relacional e web.

Ferramenta certa pra cada dado. Firebase entra pelo que é dele (mobile, push, realtime); o resto é Supabase.

Próximo da série: #12 — GCP.