Firebase: O Que é, Quanto Custa e Quando Utilizar?

Firebase é um conjunto de serviços do Google que entrega pronta a parte de trás de um aplicativo: banco de dados, login, armazenamento de arquivos, notificação e hospedagem.

A promessa é real — dá para colocar um app funcionando sem montar servidor nenhum. Mas existem consequências que só aparecem quando o projeto cresce, e é sobre elas que quase ninguém escreve.

O que vem na caixa

Authentication. Login com e-mail, telefone, Google e Apple, com recuperação de senha e verificação. Sozinho, já economiza semanas de trabalho — autenticação é fácil de fazer e difícil de fazer com segurança.

Firestore. Banco de dados em tempo real. Quando um dado muda, todos os aparelhos conectados recebem a atualização na hora, sem você programar nada para isso.

Storage. Armazenamento de fotos, PDFs e vídeos, com controle de acesso.

Cloud Functions. Código que roda no servidor sem servidor para administrar, disparado por eventos ou chamadas.

Cloud Messaging. Notificação push para iOS, Android e web. Gratuito, inclusive em volume alto.

Hosting. Publicação de site com CDN e HTTPS.

Quanto custa de verdade

O plano gratuito é generoso para desenvolver e para apps pequenos. Depois, a cobrança é por uso — e é aqui que mora a armadilha.

O Firestore cobra por operação de leitura, não por volume de dados. Cada documento lido conta.

Um exemplo concreto: uma tela de listagem que lê 50 registros, aberta 20 vezes por dia por 200 usuários, gera 200 mil leituras diárias — cerca de 6 milhões por mês. Uma tela.

A conta cresce rápido se a modelagem for descuidada. Com cache, paginação e desnormalização bem-feitos, o mesmo app pode custar um décimo. Vale muito ter alerta de orçamento configurado desde o primeiro dia.

Quando o Firebase é a escolha certa

• Protótipo ou MVP. Você precisa validar a ideia, não construir infraestrutura.
• Tempo real é o produto. Chat, colaboração, rastreio ao vivo, placar. Aqui o Firestore brilha de verdade.
• Equipe pequena. Sem gente para cuidar de servidor, um serviço gerenciado vale o preço.
• Volume imprevisível. Escala sozinho, sem você provisionar nada.
• Notificação push. Mesmo em projetos com backend próprio, usar só o Cloud Messaging é comum e faz sentido.

Quando ele não é

• Relatórios e consultas complexas. O Firestore não faz junção entre coleções nem agregação como um banco relacional. Somar vendas por vendedor por mês vira gambiarra.
• Dados muito relacionados. Sistema de gestão com cliente, pedido, item, produto, estoque e financeiro pede banco relacional. Forçar isso no Firestore dá trabalho e sai caro.
• Regras fiscais e financeiras. Transações complexas e consistência forte são o território do PostgreSQL.
• Volume alto e previsível. A partir de certo ponto, um servidor com banco próprio custa menos e é mais previsível.
• Exigência de dado no Brasil. Verifique a região dos dados se o seu contrato ou setor exigir.

O ponto que mais dói: sair depois

Firebase amarra. O Firestore não é SQL, as regras de segurança são proprietárias e as Cloud Functions têm o formato deles. Migrar um app maduro do Firebase para infraestrutura própria é um projeto por si só — normalmente de meses.

Isso não é motivo para não usar. É motivo para decidir com consciência: se o projeto tem cara de crescer para sistema de gestão com relatório pesado, comece no lugar certo.

Alternativas que valem conhecer

Supabase. Mesma ideia, mas com PostgreSQL por baixo. Você ganha SQL de verdade, relatórios e a possibilidade de hospedar por conta própria. Tem sido a nossa escolha padrão quando o projeto precisa dos dois mundos.

Backend próprio. Node ou Laravel com PostgreSQL. Mais trabalho no começo, custo previsível, controle total e nenhuma amarra.

Modelo misto. Backend próprio para os dados de negócio e Firebase apenas para notificação push e autenticação. Muito comum, e funciona bem.

Como decidir

Pergunte: daqui a dois anos, este projeto vai precisar de relatório cruzando várias entidades?

Se sim, comece com banco relacional. Se não, e tempo real for importante, Firebase entrega valor rápido.

Na dúvida, pergunte antes de construir

Escolha de backend é das decisões mais caras de reverter. Conte o que você pretende construir e damos a recomendação com o porquê — inclusive quando a resposta é usar algo que já existe pronto.