Executando verificação de segurança...
3

Com as IAs do Google (como o Google AI Studio) o firebase acaba sendo mais fácil para iniciar algo.
Mas uma coisa q acabo fazendo em um "side project" e outro é usar estrategicamente eles...
Por exemplo, eu vim do SQL, minha base é forte, mas recentemente tenho usado bastante NoSQL, e consigo notar oq cada um tem de positivo e negativo dependendo do projeto.
O ponto principal é, que em alguns projetos eu faço uma "mescla", e isso pode parecer até uma gambis (que até é), mas dá para distribuir e usar cada um individualmente no final para extrair o melhor de cada um, só saber usar e pensar muito bem na arquitetura.

Por exemplo, criei um sistema automatizador (crawler) que preciso de dados reais e um pouco menos de controle de querys, para isso usei o Firebase. Por outro lado, esse mesmo projeto tem um portal, que preciso de consistência de dados e robustez para querys, fui de supabase para esses pontos. No final ganhei o melhor dos 2 mundos no mesmo projeto.
O mesmo em outro projeto com chat em tempo real, o sistema pedia querys complexas, mas ao mesmo tempo respostas em real time, é feito a montagem de histórico e manipulação em SQL e oq preciso em real time eu filtro e uso firebase.

Resumo, da pra usar 1 ou outro, assim como dá pra usar ambos, mas isso tudo depende da necessidade do projeto.

Carregando publicação patrocinada...
1

Faz sentido usar os dois quando o projeto tem requisitos heterogêneos. Firebase brilha no tempo real, Supabase no SQL complexo, e se você consegue separar bem os domínios fica natural. No BloodLink fui de Supabase por já vir de Postgres e precisar de queries relacionais. Mas tenho curiosidade: na prática, o overhead de manter dois SDKs, duas autenticações e dois projetos no mesmo codebase não pesa? Pergunto porque parece tentador até que a complexidade operacional te pega.