TL;DR
Os dois são bons em coisas diferentes. Resumindo:
- Use Firebase se: você quer começar sem pensar em schema, prototipa rápido, e fica dentro dos limites do Firestore (queries simples, dados denormalizados).
- Use SuperDB se: você precisa de queries complexas (joins, agregações), evolução de schema sem dor, custo previsível em BRL, ou já tem time SQL.
Dica: a pergunta certa não é "qual é melhor?" — é "qual encaixa no problema?". Firestore brilha em apps com leitura massiva de documentos isolados. Postgres brilha em qualquer coisa com relações entre entidades.
Comparativo feature por feature
| Feature | SuperDB | Firebase | Observação |
|---|---|---|---|
| Tipo de DB | Postgres relacional | Firestore NoSQL | — |
| Schema | Definido (DDL) | Schemaless | Firestore = liberdade + sem garantia |
| Joins | ✓ SQL nativo | – Não nativos | Firestore: denormaliza ou faz join client-side |
| Queries | SQL completo + filtros | Limitado (1 inequality, sem OR nativo) | — |
| Realtime | Postgres changes + presence | onSnapshot | Ambos bons |
| Auth: email/senha | ✓ | ✓ | — |
| Auth: OAuth | ✓ Google, GitHub, Apple, Microsoft | ✓ + alguns extras | — |
| Auth: WhatsApp OTP | ✓ | – | SuperDB único |
| Auth: CPF/CNPJ | ✓ | – | SuperDB único |
| Auth: MFA TOTP | ✓ | ✓ | — |
| Storage | Sim, com CDN + transformações | Sim, com CDN | Firebase: mais maduro |
| Functions | Em breve (Sprint 10) | ✓ Cloud Functions | Firebase: maduro hoje |
| Cobrança | BRL, NF-e, PIX | USD, boleto via Google | SuperDB único no BR |
| Vendor lock-in | Baixo (Postgres puro) | Alto (Firestore proprietário) | — |
| Open source | AGPL-3.0 | Não | — |
| Suporte BR | PT-BR humano | EN, ticket | — |
| LGPD nativa | Export + audit hash chain | Manual | — |
| Preço pra 50k MAU | R$ 99 | ~US$ 100-300 | Firebase varia com reads/writes |
Como migrar do Firebase
Saída do Firestore exige remodelagem — NoSQL pra relacional é mudança de paradigma, não só de SDK. Resumo:
- Mapeie collections → tables. Cada coleção vira tabela; subcollections viram FK pra parent.
- Exporte via
firebase firestore:export, transforme JSON → SQL (script de migração). - Reimplemente Security Rules como políticas RLS Postgres.
- Troque
firebase/firestoreSDK por@superdb/supabase-compat.
Duração típica: 1-5 dias dependendo do tamanho. Economia ~70-90% em custo no caso de muitos reads/writes. Guia completo em /docs/guias/migrar-firebase.
Quando o Firebase é melhor
Crédito onde é devido — Firebase ganha em casos específicos:
- Prototipagem ultra-rápida sem schema — você só joga JSON e ele aceita. Ótimo pra hackathon ou MVP de 1 fim de semana.
- Cloud Functions hoje — produto maduro, com cold start aceitável, debugging via Google Cloud. SuperDB tem Edge Functions só na Sprint 10.
- Ecossistema Google integrado — Analytics, AdMob, FCM (push notif), Crashlytics, Remote Config. Se você quer tudo no mesmo pacote, Firebase entrega.
- Apps mobile-first com offline-first complexo — Firestore SDK tem sync offline robusto (>10 anos de iteração).
Quando o SuperDB é melhor
- App brasileiro — BRL, NF-e automática, PIX recorrente, CPF/CNPJ no auth, dados no Brasil pra LGPD.
- Queries complexas — joins, agregações, reports SQL. Tente fazer "top 10 vendedores por região do último trimestre" no Firestore.
- Custo previsível — mensal fixo. Firebase cobra por read/write/storage/egress; uma feature ruim pode quadruplicar a conta sem aviso.
- Postgres você já conhece — 80% dos devs sabem SQL. Reaproveita conhecimento.
- Multi-tenant SaaS — RLS por tenant em Postgres é trivial. Em Firestore exige cuidado redobrado com Security Rules.
Dúvida frequente: "mas Firebase é Google, mais confiável?" — disponibilidade GCP e disponibilidade SuperDB são, na prática, similares pra Brasil (latência de SP é melhor no SuperDB). O que muda é o tipo de risco: Google pode descontinuar produto (já fez), SuperDB pode quebrar como empresa (open source mitiga).