Firebase ou back-end próprio: qual escolher para o seu app?

Todo aplicativo tem duas metades. A que o usuário vê, no celular, e a que ninguém vê: o servidor que guarda os dados, confere quem pode fazer o quê, manda notificações e conversa com os outros sistemas da empresa. Na hora de começar um app, a pergunta sobre essa segunda metade costuma aparecer assim: "dá para fazer tudo no Firebase ou precisamos de um back-end próprio?".

A dúvida é legítima. O Firebase, plataforma do Google para apps móveis e web, entrega pronto muito do que um back-end faria. Mas a mesma conversa costuma voltar meses depois, quando o app cresceu e a pergunta virou "como saímos daqui?".

Este texto explica o que cada caminho entrega, onde cada um aperta e como decidir olhando para a operação da empresa, não para a preferência da equipe técnica. E mostra como projetar a saída antes de entrar, qualquer que seja a escolha.

Resposta curta: decida pela complexidade das regras de negócio e pelo volume de integrações. Se o app tem dados simples, precisa de login e notificações e vive quase sozinho, o Firebase acelera muito. Se há regras transacionais, relatórios cruzados, integração com ERP ou exigências de LGPD sobre onde o dado fica, um back-end próprio tende a ser o caminho mais seguro, às vezes com o Firebase ao lado só para login e push.

O que o Firebase entrega pronto: autenticação, banco, push, hospedagem e funções

O Firebase é um conjunto de serviços gerenciados, contratados no modelo de nuvem: você não instala servidor, não cuida de sistema operacional e a cobrança acompanha o uso. Os blocos mais usados em apps de empresa são estes:

• Autenticação. Cadastro e login com e-mail e senha, telefone e provedores conhecidos, com boa parte dos fluxos básicos (recuperação de senha, verificação de e-mail) já resolvida.
• Banco de dados de documentos. O Firestore guarda dados em coleções de documentos, sincroniza em tempo real com o aparelho e tem suporte a uso offline. É um banco NoSQL, e é nele que este texto se concentra, por ser o banco mais usado em apps feitos no Firebase.
• Notificações push. O Cloud Messaging entrega mensagens para Android, iOS e web a partir de um único serviço.
• Hospedagem. Para o site ou a versão web do app.
• Funções. Pequenos trechos de código que rodam no servidor quando algo acontece: um documento novo, uma chamada HTTP, um horário agendado.

O ganho real está na velocidade do começo: uma equipe pequena coloca no ar um app com login, dados sincronizados e notificações sem montar infraestrutura.

O Google amplia e ajusta esses serviços com frequência, inclusive com uma opção que liga o projeto Firebase a um banco relacional gerenciado. Ela reduz parte das limitações descritas abaixo, mas muda o modelo de trabalho e merece avaliação própria. Antes de decidir, confirme com o fornecedor o que existe hoje, em quais regiões e com quais condições.

O que um back-end próprio entrega: regra de negócio no servidor, banco relacional e controle total

"Back-end próprio" não significa servidor na sala da empresa. Significa uma aplicação de servidor escrita para o seu negócio, rodando numa nuvem que você escolhe, com um banco de dados que você controla. Ele entrega três coisas que fazem diferença à medida que o app cresce:

• A regra mora no servidor. O app pede "faça este pedido", e o servidor decide se pode, calcula preço, desconto e imposto, reserva estoque e grava tudo junto. O celular só exibe e envia. Isso protege a regra de quem tenta manipular o app, um ponto que detalhamos em segurança em aplicativos móveis.
• Banco relacional. Tabelas ligadas por chaves, consultas que juntam pedido, cliente, item e vendedor numa única pergunta, e transações que garantem que ou tudo é gravado, ou nada é. Para dinheiro e estoque, isso pesa. A comparação completa está em banco de dados relacional ou NoSQL.
• Controle total. Você escolhe a região dos dados, a forma de backup, as bibliotecas, o modelo de API e a hora de migrar de provedor de nuvem.

O preço desse controle é trabalho: autenticação, deploy, monitoramento, atualizações e escala passam a ser responsabilidade de alguém. Esse esforço só se paga quando o app realmente precisa disso.

Regras de negócio e consultas: onde o Firestore começa a apertar

O Firestore é ótimo para o que foi desenhado: ler e gravar documentos com estrutura previsível, filtrados por poucos campos, e mantê-los sincronizados com muitos aparelhos. O aperto aparece quando o app começa a se comportar como sistema de gestão.

Consultas que cruzam muitas coisas

"Quanto cada vendedor faturou por região, só em clientes ativos, no trimestre, descontando devoluções?" Num banco relacional, isso é uma consulta. Num banco de documentos, normalmente significa duplicar dados entre coleções, manter contadores atualizados por funções ou exportar tudo para outro lugar antes de responder. Funciona, mas cada nova pergunta da diretoria vira um pequeno projeto.

Regras que precisam de transação

Reservar o último item do estoque, aprovar um pedido acima do limite de crédito, baixar uma comissão quando o pagamento entra. Essas operações precisam acontecer inteiras ou não acontecer. O Firestore tem recursos de transação, mas eles foram pensados para o modelo de documentos. Quando a regra envolve muitas entidades e muitas exceções, a lógica tende a se espalhar entre regras de segurança, funções e o próprio app.

Regras de segurança fazendo papel de regra de negócio

No Firebase é comum o app falar direto com o banco, protegido por regras de segurança declarativas. Para "cada usuário só lê os próprios dados", isso resolve bem. Para "o gerente aprova até certo valor, acima disso vai para a diretoria, exceto em cliente estratégico", as regras ficam difíceis de ler, testar e auditar. Um sinal de alerta: quando a equipe tem medo de mexer nas regras de segurança, a regra de negócio já está no lugar errado.

Integração com ERP, relatórios e auditoria

App de empresa raramente vive sozinho: o pedido precisa chegar ao ERP, o estoque precisa aparecer no app e o auditor quer saber quem alterou o quê.

• Integração com ERP. Integrar exige fila, nova tentativa quando o ERP está fora, mapeamento de cadastros e definição de quem é a fonte da verdade de cada dado. Dá para fazer isso com funções do Firebase, mas cada integração vira um conjunto de funções soltas reagindo a eventos. Com várias integrações, um back-end com uma camada de integração organizada é mais fácil de manter. O passo a passo está em como integrar seu sistema com o ERP.
• Relatórios. Se a gestão vai tirar números do app, os dados vão precisar ir para um banco relacional ou um armazém analítico de qualquer forma. Vale perguntar se não é melhor que já nasçam lá.
• Auditoria. Registrar quem fez cada alteração, com valor anterior e novo, é muito mais simples quando toda escrita passa pelo servidor. Quando o app grava direto no banco, a trilha depende de funções que reagem depois do fato. Veja o que uma trilha bem feita precisa ter em perfis de acesso e trilha de auditoria.

Regra prática: uma integração simples convive bem com o Firebase. Duas ou três integrações com regras próprias, mais relatórios gerenciais, costumam pedir um back-end.

Custo: como cada modelo cobra

O custo de infraestrutura raramente decide sozinho, mas o jeito de cobrar muda o tipo de risco.

No Firebase, a cobrança acompanha o uso: no Firestore, cada documento lido, gravado ou apagado conta, além do armazenamento e da execução das funções. Para um app pequeno, isso costuma sair barato, e há uma faixa de uso sem custo para começar. O ponto de atenção é que a conta depende do desenho do app. Uma tela que carrega uma lista inteira toda vez que abre, ou um contador recalculado a cada gravação, multiplica as operações sem ninguém perceber. Configure alertas de orçamento desde o primeiro dia e revise as telas mais acessadas.

No back-end próprio, a infraestrutura costuma ter um custo base que existe mesmo com pouco uso: servidor, banco gerenciado, backup e monitoramento. Em compensação, a conta varia menos com o comportamento do app. O custo que mais pesa aqui é outro: as horas de quem mantém o servidor atualizado, seguro e no ar.

Na comparação, inclua os dois lados: a fatura da nuvem e o tempo da equipe. Um Firebase mais barato na fatura pode sair caro se cada relatório novo exigir duplicar dados e escrever funções; um back-end próprio pode ser exagero para um app que nunca vai passar de algumas centenas de usuários.

Dependência de fornecedor, LGPD e localização dos dados

Dependência de fornecedor

Todo serviço gerenciado cria algum grau de dependência, e isso não é motivo para evitá-lo. O que pesa é quanto do seu código depende do jeito específico daquele serviço. No Firebase, o app costuma conversar diretamente com o banco usando o SDK do fornecedor, e as regras de segurança e as funções seguem o modelo da plataforma. Trocar depois significa reescrever partes do app, não só do servidor.

No back-end próprio também há dependência (da nuvem, do banco, do framework), mas ela costuma ser mais intercambiável: um banco relacional padrão e uma API própria mudam de provedor com menos atrito.

LGPD e onde o dado fica

A LGPD não obriga, como regra geral, a manter dados pessoais no Brasil. Ela permite a transferência internacional em hipóteses previstas na lei, e alguns setores e contratos trazem exigências próprias. Explicamos o tema em dados na nuvem no Brasil e LGPD.

Na prática, as perguntas que precisam de resposta antes de escolher são:

• O seu cliente ou o seu setor exige que os dados fiquem em território nacional?
• Cada serviço que você vai usar permite escolher a região? Os dados de autenticação, logs e notificações seguem a mesma região do banco?
• Você consegue atender um pedido de exclusão do titular apagando o dado em todos os lugares onde ele foi copiado?
• O contrato com o fornecedor cobre o papel de operador de dados?

No Firebase, parte dessas respostas depende do serviço específico e das condições do Google no momento, e por isso precisam ser confirmadas com o fornecedor. No back-end próprio, você escolhe a região e o desenho, mas também assume a responsabilidade de fazer certo. Os requisitos técnicos da lei estão em LGPD no software.

Tabela comparativa: Firebase x back-end próprio

Quando escolher cada um (e o caminho híbrido: Firebase só para push e login)

O Firebase é a melhor escolha quando

• O app é um MVP ou piloto, e a prioridade é descobrir se as pessoas vão usar.
• Os dados são simples e pertencem a cada usuário: checklists, agendamentos, catálogos, conteúdos.
• Há pouca ou nenhuma integração com outros sistemas da empresa.
• Tempo real e uso offline são centrais na experiência.
• A equipe é pequena e não quer cuidar de infraestrutura agora.

Nesses casos, montar back-end próprio é gastar energia antes da hora.

O back-end próprio é a melhor escolha quando

• O app movimenta dinheiro, estoque, crédito ou comissão.
• A regra de negócio tem muitas exceções e muda com frequência.
• O app precisa conversar com ERP, sistema fiscal, CRM ou outros sistemas.
• A gestão vai cobrar relatórios cruzados a partir dos dados do app.
• Há exigência contratual ou setorial sobre onde o dado fica, ou necessidade forte de auditoria.
• O mesmo servidor vai atender o app, um portal web e parceiros por API.

O caminho híbrido

Muitas vezes a melhor resposta é dividir. O back-end próprio guarda os dados e as regras; o Firebase entra só no que faz muito bem:

• Push. O servidor decide quem notificar e quando, e usa o Cloud Messaging apenas para entregar. As boas práticas para não cansar o usuário estão em notificações push.
• Login. O Firebase autentica o usuário, o back-end confere o token e aplica as permissões do negócio.

Assim a empresa ganha velocidade nas partes genéricas sem prender a regra de negócio ao fornecedor.

Projete a saída antes de entrar

Qualquer que seja a escolha, algumas decisões no começo deixam a troca possível depois:

1. Coloque uma camada entre o app e o banco. Mesmo usando Firebase, faça o app chamar funções ou um módulo de acesso a dados, em vez de espalhar consultas ao banco pelas telas.
2. Modele os dados pensando em tabelas. Documentos com identificadores estáveis e relações explícitas migram para um banco relacional com muito menos dor.
3. Mantenha a regra de negócio em um só lugar. Se for no Firebase, nas funções do servidor, não no app.
4. Tenha exportação periódica dos dados. Uma cópia regular num formato aberto é seguro contra surpresa e base para relatórios.
5. Anote os gatilhos de migração. Por exemplo: "quando entrar a segunda integração" ou "quando a diretoria pedir relatório por região". Quando o gatilho disparar, a decisão já está tomada.

A escolha do servidor também conversa com a escolha do app em si. Se a dúvida ainda é qual tecnologia usar no celular, veja app nativo, híbrido ou PWA. Outros textos sobre o tema estão em aplicativos.

Perguntas frequentes

O Firebase é gratuito?

Em parte. O Firebase tem uma faixa de uso sem custo para começar e, depois dela, a cobrança acompanha o uso: no Firestore, cada documento lido, gravado ou apagado conta, além do armazenamento e da execução das funções. Como a conta depende do desenho das telas do app, vale configurar alertas de orçamento desde o primeiro dia.

Dá para migrar do Firebase para um back-end próprio depois?

Sim, mas o esforço depende de como o app foi construído. Como o app costuma conversar direto com o Firestore pelo SDK do Google, migrar significa reescrever partes do app, não só do servidor. Uma camada entre as telas e o banco, dados modelados pensando em tabelas e exportação periódica deixam a migração para back-end próprio bem mais simples.

O Firebase atende à LGPD?

Depende do uso e da configuração. A LGPD não obriga, como regra geral, a manter dados pessoais no Brasil, mas alguns setores e contratos exigem isso. No Firebase, a região de cada serviço, como autenticação, banco e notificações, precisa ser confirmada com o Google, e a empresa continua responsável por atender pedidos de exclusão feitos pelo titular.

O que é o Firestore?

Firestore é o banco de dados de documentos do Firebase, do tipo NoSQL, que guarda informações em coleções de documentos, sincroniza em tempo real com os aparelhos e funciona offline. O Firestore é ótimo para dados simples e previsíveis, mas consultas que cruzam muitas entidades e regras transacionais complexas ficam mais naturais num banco de dados relacional.

Como a Pervian Tech ajuda a decidir na arquitetura do seu app

Começamos pelo que o app precisa fazer no negócio, não pela ferramenta: quais regras ele executa, com quais sistemas conversa, quem vai consumir os dados e que exigências de contrato e de LGPD existem. A partir disso, o trabalho de arquitetura de software define onde cada parte deve rodar e como a saída fica planejada desde o começo.

O diagnóstico inicial é gratuito. Quando o Firebase atende, recomendamos o Firebase e ajudamos a montar com as precauções certas. Quando o app precisa de back-end próprio, ou do caminho híbrido, construímos isso dentro do desenvolvimento de aplicativos para empresas, em fases: diagnóstico, protótipo, MVP e evolução. O investimento é definido sob consulta, depois de entender o escopo.

Se o seu app está para começar, ou já começou e a dúvida apareceu no meio do caminho, conte para nós como ele é hoje.