Seu backend criado por IA deve sair do Firebase?

Um aplicativo deve sair do Firebase quando seu modelo de dados, suas regras de autorização ou seus fluxos de servidor ficam mais difíceis de entender do que o próprio produto. Ele não deve sair apenas porque a equipe ouviu que Postgres é mais sério. Uma reescrita apressada pode trocar um conjunto de restrições por uma interrupção, contas perdidas e meses de comportamento dividido entre dois sistemas.

Para a maioria das equipes que superaram o Firestore, o Supabase é um meio-termo prático: dados relacionais, SQL, autenticação gerenciada, armazenamento, funções e uma API gerada em um só serviço. Um serviço de Postgres gerenciado dá mais controle e impõe menos convenções a equipes experientes, mas também deixa a cargo delas montar autenticação, APIs, armazenamento de arquivos, trabalhos em segundo plano, observabilidade e implantação. Permanecer no Firebase ainda pode ser a escolha certa quando o modelo de documentos se encaixa e a equipe consegue corrigir regras e funções sem lutar contra a plataforma.

O destino depende da restrição que você não pode continuar pagando

Escolha o destino nomeando a restrição que já consome tempo de engenharia. Se ninguém consegue descrevê-la em uma frase, a equipe ainda não está pronta para migrar. Uma queixa vaga como «Firebase não escala» não é um diagnóstico. O Firestore pode lidar com cargas grandes; a pergunta útil é se seus padrões de acesso e seu modelo de consistência ainda servem a este aplicativo específico.

O Firebase continua adequado quando os clientes leem e gravam principalmente documentos independentes, o funcionamento offline importa, os listeners em tempo real são centrais e Security Rules consegue expressar o acesso sem duplicar o estado do negócio. A migração ganha força quando uma ação precisa atualizar vários registros relacionados, relatórios exigem junções entre coleções, a integridade referencial deve ficar no banco ou Cloud Functions virou o único lugar onde alguém entende as regras reais.

O Supabase atende equipes que querem a semântica do Postgres sem construir todos os serviços ao redor. Ele reduz o número de decisões durante a mudança, algo que importa quando uma ferramenta de IA montou o código atual e ninguém tem um mapa confiável. Suas convenções também criam limites: Supabase Auth tem seu próprio ciclo de vida, a API de dados gerada depende da segurança em nível de linha e as funções da plataforma não são idênticas a um servidor de aplicação geral.

Postgres gerenciado atende quando a equipe já sabe qual framework web, provedor de identidade, sistema de tarefas, serviço de armazenamento e conjunto de monitoramento deseja. O banco é portátil, mas a equipe precisa projetar e operar o backend. Essa liberdade só existe quando alguém assume essas decisões.

Use uma tabela simples antes de discutir fornecedores. Dê um ponto ao destino favorecido por cada afirmação:

A pontuação não toma a decisão. Ela expõe o argumento. Qualquer linha que ninguém consiga pontuar com evidências vira uma tarefa de descoberta antes da migração.

O esforço de migração se esconde no comportamento, não na contagem de registros

Um milhão de documentos simples pode ser mais fácil de mover do que dez mil cujo significado depende de gatilhos, horários do cliente, contadores desnormalizados e Security Rules. A quantidade de registros afeta o tempo de transferência. O acoplamento do comportamento determina o projeto.

Comece mapeando todo caminho capaz de alterar estado persistente. Em um código gerado por IA, não suponha que o cliente de banco mais óbvio seja o único gravador. O navegador pode escrever diretamente no Firestore, rotas do servidor podem usar Admin SDK, funções agendadas podem corrigir contadores, webhooks podem atualizar pagamentos e scripts de implantação podem criar documentos iniciais. Procure inicializações de SDK, nomes de coleções, funções chamáveis, acessos a buckets e variáveis de ambiente. Depois, compare esse mapa com logs de produção e configurações da nuvem. A busca no código não encontra funções implantadas que já não existem no repositório.

Classifique cada gravação pela garantia de que precisa. Uma edição de perfil costuma aceitar uma atualização direta. A confirmação de um pedido pode exigir transação, idempotência, evento imutável e política de repetição. Um contador mantido por um gatilho do Firestore pode virar um agregado SQL, um gatilho do banco ou uma projeção assíncrona. Esses três desenhos falham de maneiras diferentes. Copiar o gatilho linha por linha para uma nova função preserva uma solução antiga depois que o banco removeu a limitação original.

Estime o trabalho em quatro grupos: transformação de dados, mudança de identidade, substituição de fluxos e integração do cliente. A transformação inclui achatar documentos aninhados, promover valores repetidos a tabelas, escolher tipos e resolver referências órfãs. A mudança de identidade inclui hashes de senha, provedores vinculados, sessões, modelos de email, URLs de redirecionamento e recuperação de conta. A substituição de fluxos cobre funções, filas, tarefas agendadas, webhooks e eventos de armazenamento. A integração do cliente cobre mudanças de consulta, estados de carregamento, pressupostos offline, tratamento de erros e verificações de autorização.

Um arquivo de inventário torna a estimativa revisável. Pode ser um JSON simples guardado ao lado do código de migração:

{
  "source": "firestore",
  "collections": {
    "orders": {
      "writers": ["web-checkout", "payment-webhook"],
      "readers": ["account-page", "support-console"],
      "rules": ["owner-read", "support-read"],
      "side_effects": ["send-receipt", "increment-customer-total"]
    }
  }
}

O artefato evita uma falha conhecida: a equipe migra as telas visíveis, declara o banco concluído e descobre depois que um webhook antigo ainda grava apenas no Firestore. Adicione todos os gravadores antes de atribuir datas. Se uma coleção tem um gravador desconhecido ou um campo sem explicação, a descoberta não terminou.

Uma exportação do Firestore é uma fonte, não um esquema Postgres

A exportação gerenciada do Cloud Firestore produz arquivos de log LevelDB e metadados no Cloud Storage. A documentação do Firebase a descreve como uma exportação que pode ser importada para outro banco Firestore ou carregada no BigQuery sob certas condições. Não é um dump relacional que pg_restore consiga consumir, nem um snapshot exato tirado no início da operação. Trate-a como material de origem para uma transformação controlada.

A migração precisa de um mapeamento explícito entre caminhos de documentos e tabelas. Um documento como customers/{customerId}/orders/{orderId} carrega uma relação no caminho. No Postgres, essa relação normalmente pertence a uma chave estrangeira orders.customer_id. Arrays de etiquetas primitivas podem continuar como arrays. Arrays de objetos que mudam de forma independente costumam virar linhas filhas. Campos de mapa podem virar colunas tipadas quando o produto os consulta, ou jsonb quando a forma é realmente aberta. Escolher jsonb para todos os documentos facilita a primeira importação e mantém as fraquezas do modelo antigo.

O Firestore permite campos ausentes e tipos diferentes entre documentos. O Postgres pede um tipo e deixa o esquema aplicá-lo. Analise a fonte antes de fechar as tabelas: conte campos ausentes, liste os tipos observados, encontre identificadores naturais duplicados e identifique referências a documentos apagados. Decida como tratar cada anomalia. Uma conversão silenciosa, como transformar uma data inválida em null, deixa a importação passar e leva um erro latente para produção.

Para o Supabase, as ferramentas comunitárias de migração do Firebase podem converter coleções do Firestore em JSON e importar dados transformados, mas não entendem as relações que o aplicativo pretende. Para Postgres gerenciado, um extrator e carregador próprio costuma ser mais claro. Nos dois casos, torne a transformação determinística: o mesmo registro de origem deve sempre produzir a mesma linha e o mesmo identificador. Mantenha uma coluna com o ID de origem até a conciliação terminar.

Um esquema de destino útil aplica as afirmações que o aplicativo já faz. Este trecho dá propriedade estável aos pedidos e impede que entregas repetidas de webhook criem duplicatas:

create table customers (
  id uuid primary key,
  firebase_uid text unique,
  email text not null
);

create table orders (
  id uuid primary key,
  customer_id uuid not null references customers(id),
  provider_event_id text not null unique,
  status text not null check (status in ('pending', 'paid', 'cancelled')),
  created_at timestamptz not null
);

Depois da carga, concilie fatos em vez de confiar em um código de saída correto. Compare contagens por categoria do negócio, somas monetárias na menor unidade, datas mínimas e máximas, quantidade de proprietários distintos e uma amostra de registros entre origem e destino. Guarde as consultas no controle de versão. Uma migração que não pode ser repetida e verificada é improvisação de uso único, não um processo de lançamento.

A autenticação se move separada dos dados do aplicativo

Contas de usuário não são linhas comuns, porque uma conta válida inclui credenciais, identidades de provedores, estado de verificação, sessões, recuperação e referências nos dados do aplicativo. Migrar uma coleção users não migra Firebase Authentication, mesmo quando ambos usam o mesmo UID.

Firebase CLI aceita auth:export, e o Firebase expõe os parâmetros de hash necessários para importações compatíveis. O guia do Supabase para migrar Firebase Auth usa uma ferramenta em duas partes: exporta usuários do Firebase para JSON e os importa na tabela de destino auth.users. O guia também manda preservar os parâmetros SCRYPT do Firebase, incluindo chave de assinatura, separador de sal, rodadas e custo de memória. Esse detalhe define a diferença entre manter o login normal de usuários com senha e obrigar todos a recuperar a conta.

Não suponha que toda identidade será transferida sem problemas. Faça um inventário de contas por senha, link de email, telefone, usuários anônimos e cada provedor OAuth. Confira se uma pessoa tem provedores vinculados sob um só UID. Verifique se o destino mantém os identificadores do provedor e como trata emails duplicados. Claims personalizadas precisam de um local explícito, talvez tabelas de autorização ou claims assinadas. Sessões normalmente não passam entre sistemas de autenticação diferentes, portanto planeje expiração do token, nova autenticação e uma mensagem clara ao usuário.

Há três padrões de mudança defensáveis. Uma redefinição forçada é a opção mais simples, mas gera atendimento e deve ser decisão de produto. Uma importação em massa de hashes preserva a verificação quando o destino aceita o algoritmo e os parâmetros da fonte. Uma migração gradual valida a credencial antiga no primeiro login, cria ou atualiza a identidade de destino e deixa de consultar o sistema anterior para esse usuário. Ela reduz o impacto do primeiro dia, mas prolonga o período em que dois sistemas podem conceder acesso.

Qualquer que seja o padrão, crie um mapeamento imutável de identidade antes de mover linhas de negócio:

firebase_uid                         postgres_user_id
n7Yx...                              2d99150e-3b33-4afb-9c5b-7cbd20b91a4d

Nunca junte registros por email durante a migração. Pessoas mudam de endereço, provedores podem normalizá-lo de formas diferentes e duplicatas aparecem depois de anos de importações. Use o UID da fonte como identidade de migração e depois associe o ID de destino. Teste usuários desativados, não verificados, apagados com dados remanescentes, usuários que só usam um provedor e recuperação de conta. O fluxo feliz de login por senha prova muito pouco.

A autorização precisa ser reescrita, não traduzida

Firestore Security Rules e a segurança em nível de linha do Postgres respondem a perguntas parecidas por modelos de execução diferentes. Uma tradução mecânica é perigosa. As regras do Firestore avaliam uma solicitação contra caminhos de documentos e os dados propostos. Políticas do Postgres filtram linhas em operações SQL, enquanto funções e permissões definem quais objetos podem ser acessados. Código de servidor com credenciais privilegiadas pode contornar os dois sistemas, por isso a fronteira de confiança importa tanto quanto a sintaxe.

Primeiro escreva uma matriz de acesso na linguagem do produto. Para cada recurso, declare quem pode selecionar, inserir, atualizar e apagar, além dos campos ou mudanças de estado permitidos. «Usuários podem atualizar o próprio perfil» é incompleto se a mesma linha contém is_admin. «Proprietários podem atualizar pedidos» está errado se clientes podem mudar status de pending para paid.

Uma política do Supabase para selecionar os próprios pedidos pode ser assim:

alter table orders enable row level security;

create policy "customers read own orders"
on orders for select
to authenticated
using (customer_id = auth.uid());

Essa política só funciona se orders.customer_id guardar o mesmo UUID retornado por auth.uid(). Se a linha importada tiver um UID textual do Firebase e o token novo tiver um UUID do Supabase, a política não retorna linhas. Se alguém desativar a segurança em nível de linha para fazer a tela funcionar, ela pode retornar todas. O mapeamento de identidade e o desenho do esquema fazem parte da revisão de autorização.

Postgres gerenciado não fornece auth.uid() a menos que o aplicativo crie um contexto de sessão equivalente ou sempre filtre por código confiável no servidor. Muitas equipes escolhem a segunda opção: os clientes chamam uma API, ela verifica a identidade e o SQL recebe o ID autenticado como parâmetro. Esse modelo é mais fácil de inspecionar em uma base de código, mas todo endpoint deve aplicar a autorização. Acesso direto do navegador ao banco exige desenho de funções e testes de política mais rígidos.

Teste negações, não apenas sucessos. Para cada função, tente ler a linha de outro cliente, mudar uma coluna de propriedade, atualizar um estado protegido, inserir um proprietário alheio e chamar a operação por todas as rotas públicas. Rode os testes com as mesmas credenciais públicas e claims usadas pelo cliente. Uma consulta no console administrativo não prova isolamento.

Fluxos personalizados decidem se o Supabase basta

O Supabase costuma bastar quando o comportamento pode viver em restrições SQL, funções do banco, funções edge, tarefas agendadas, webhooks e um número moderado de trabalhos em segundo plano. Postgres gerenciado fica mais claro quando o produto precisa de workers longos, runtimes especializados, filas complexas, redes privadas ou controle de implantação que entraria em conflito com o modelo de funções da plataforma.

Liste as Cloud Functions atuais pelo tipo de gatilho, não pelo nome do arquivo. Funções HTTP são APIs. Funções chamáveis ligam o cliente ao protocolo de invocação do Firebase. Gatilhos do Firestore reagem a mudanças de dados. Hooks de autenticação reagem a eventos de identidade. Gatilhos de armazenamento processam arquivos. Funções agendadas fazem manutenção. Cada categoria precisa de um destino com comportamento equivalente de entrega e repetição.

Preste atenção especial à entrega pelo menos uma vez. Um webhook de pagamento, evento de armazenamento ou mensagem de fila pode chegar duas vezes, mesmo que isso não seja comum. O novo handler deve reivindicar o ID do evento na mesma transação que altera o estado. A restrição única do esquema anterior transforma a segunda entrega em uma duplicata detectável. Uma flag na memória ou uma linha de log não oferece essa garantia entre instâncias.

Não coloque todo fluxo em um gatilho do banco só porque o Postgres consegue executá-lo. Gatilhos funcionam bem para invariantes locais e pequenas mudanças derivadas que devem compartilhar uma transação. São locais ruins para chamar APIs de terceiros, enviar email ou processar mídia lentamente. Essas ações precisam de uma tarefa durável e um worker que repita com idempotência. O banco deve confirmar a mudança de negócio e enfileirar a intenção na mesma transação.

A recomendação popular de reescrever tudo em SQL atrai porque remove código da aplicação. Ela está errada quando esconde fluxos em funções que o restante da equipe não consegue implantar, rastrear nem testar. Coloque regras de consistência perto dos dados. Coloque a orquestração em um serviço com logs, limites de tempo, repetições e um responsável. O Supabase pode hospedar uma versão pequena desse serviço; um desenho de Postgres gerenciado presume que a equipe o escolherá e operará em outro lugar.

A carga operacional é o trabalho que sobra depois do lançamento

A diferença operacional não é «gerenciado contra não gerenciado». Firebase, Supabase e Postgres gerenciado administram infraestrutura em algum nível. A comparação útil pergunta quais falhas continuam sendo suas e se a equipe consegue detectá-las e corrigi-las.

O Firebase remove a maior parte da administração do banco, mas a equipe ainda responde por Security Rules, índices, cotas, implantações de funções, surpresas de custo, escolha de região e recuperação do aplicativo. O Supabase gerencia Postgres e agrupa vários serviços, mas a equipe responde por migrações de esquema, políticas por linha, conexões, desempenho de consultas, compatibilidade de extensões e interação entre componentes. Um provedor de Postgres gerenciado cuida do processo do banco, backups e parte da manutenção, enquanto a equipe cuida da API e de cada serviço auxiliar escolhido.

Pergunte quem fará cinco trabalhos recorrentes: aplicar uma mudança de esquema sem quebrar clientes antigos, restaurar dados para um ponto conhecido, responder a uma credencial de servidor vazada, diagnosticar uma solicitação lenta entre serviços e trocar um segredo de autenticação. Se a resposta é um fundador que nunca viu a configuração de implantação, Postgres gerenciado mais uma pilha própria é um primeiro passo grande demais. Se uma equipe de backend experiente já opera esses controles, as convenções de uma plataforma podem atrapalhar mais do que ajudar.

Comparações de custo exigem a mesma carga e as mesmas premissas de falha. O Firestore cobra operações e armazenamento segundo seu modelo. Planos de Postgres costumam agrupar computação e depois limitar conexões, memória, armazenamento ou vazão. Uma consulta que lê um agregado relacional não se compara a um cliente que busca centenas de documentos, e uma instância dimensionada para o pico não se compara ao custo ocioso sem servidor. Reproduza consultas parecidas com produção em um destino de teste e registre latência, linhas tocadas, uso de conexões e trabalho de ajuste. Não extrapole a partir de uma demonstração vazia.

A portabilidade também tem camadas. Tabelas SQL se movem entre provedores de Postgres com mais facilidade do que dados do Firestore entram em um esquema relacional. Supabase Auth, metadados de armazenamento, APIs geradas, políticas e funções edge ainda criam trabalho de migração. Isso é aceitável quando esses serviços economizam hoje mais trabalho do que podem custar depois. Chamar qualquer backend de «sem dependência» esconde as dependências da aplicação que importam.

Uma mudança segura mantém uma autoridade para cada gravação

A migração mais segura separa a cópia de dados da troca de autoridade. Durante a cópia, o Firestore continua autoritativo. Durante a mudança, cada entidade de negócio deve ter um só gravador autoritativo. Gravar nos dois sistemas por semanas sem conciliação cria duas versões plausíveis e dificulta, em vez de facilitar, o retorno.

Use esta sequência como base:

1. Congele mudanças de esquema e inventarie todos os leitores, gravadores, funções, regras, índices e segredos.
2. Construa o esquema de destino, o mapeamento de identidade, os testes de autorização e a importação determinística em ambiente isolado.
3. Ensaie uma migração completa a partir de uma exportação nova, registre a duração e concilie fatos do negócio.
4. Copie os dados mais recentes, capture mudanças ocorridas desde o início e pause gravações na fonte para aplicar o delta final.
5. Troque primeiro os gravadores do servidor e depois os clientes, monitore ambos os sistemas e mantenha uma rota testada de volta até que novas gravações a tornem insegura.

Um plano com pouca indisponibilidade pode usar captura de mudanças ou gravação dupla temporária, mas precisa de uma regra de conflito e um livro de conciliação. Registre o ID da operação de origem, a transação de destino, a entidade, o resultado e o estado da repetição. Decida antes se a origem ou o destino vence quando ambos mudam. Se ninguém sabe explicar como corrigir a segunda gravação que falhou, a gravação dupla não é segura.

Mantenha a compatibilidade no limite da API quando possível. Se os clientes já chamam uma API do aplicativo, mude a implementação do armazenamento e preserve o contrato. Se falam diretamente com o Firestore, introduza uma camada de repositório ou uma nova API antes de mover cada tela. Essa separação parece mais lenta na primeira semana e evita edições repetidas no restante do lançamento.

Defina retorno como um procedimento testado com prazo. Antes de começar a gravar no destino, pode significar apontar os clientes de volta e descartar o destino. Depois que registros exclusivos do destino existirem, o retorno exige transformação inversa ou pausa de gravações. Declare o evento exato que fecha a janela fácil. Um backup ajuda, mas não é um plano até que a equipe o tenha restaurado e medido o tempo.

O código pode precisar de reparo antes que o backend seja movido

Uma migração amplia tudo o que o aplicativo atual não tornou explícito. Projetos gerados costumam misturar credenciais do navegador e do servidor, duplicar chamadas ao banco entre componentes, confiar em IDs de proprietário enviados pelo cliente e esconder regras de negócio em eventos da interface. Mover essas chamadas para Supabase ou Postgres sem mudar as fronteiras transfere os defeitos.

Execute a migração só depois de responder quatro perguntas sobre o código. Quais módulos podem acessar o banco? Onde a identidade do servidor vira um ID de usuário confiável? Qual serviço possui cada mudança de estado? Qual ambiente pode ler segredos privilegiados? Se as respostas mudam por tela, estabeleça primeiro uma pequena fronteira de acesso a dados. Ela não precisa ser elegante. Precisa tornar todas as gravações visíveis e testáveis.

O tratamento de segredos merece uma verificação própria. A configuração web do Firebase identifica um projeto e é protegida por Security Rules e pela configuração do serviço, enquanto credenciais do Admin SDK concedem acesso privilegiado. O Supabase tem credenciais públicas de cliente projetadas para políticas por linha e credenciais privilegiadas de servidor que contornam restrições normais. Strings de conexão de Postgres gerenciado normalmente pertencem ao servidor, nunca ao navegador. Substituições automáticas confundem essas categorias porque todas parecem variáveis de ambiente.

FixMyMess pode auditar um aplicativo de IA herdado, corrigir autenticação e lógica, reforçar a segurança, refatorar o código e preparar a implantação antes ou durante a mudança. O resultado útil não é trocar de fornecedor; é ter um sistema cuja propriedade dos dados, caminhos privilegiados e processo de lançamento uma pessoa consiga explicar.

Não migre um código que não passa por uma auditoria básica dos caminhos de gravação. Estabilize identidade e invariantes do negócio, escolha o menor destino que os suporta e ensaie até a conciliação ficar rotineira. Firebase, Supabase e Postgres gerenciado podem executar um produto sólido. Nenhum deles fornece o modelo ausente de como esse produto deveria se comportar.