Alternativas ao Firebase no Brasil.

A resposta curta

O Firebase continua sendo uma boa escolha para muita gente. Ele começa sem schema, sincroniza offline muito bem no celular e junta Analytics, Crashlytics e Remote Config no mesmo console. Se o seu app vive disso, talvez a troca não compense.

As pessoas costumam procurar alternativa por quatro motivos, e cada um aponta para um lugar diferente:

• O dado ficou relacional. Pedidos com itens, clientes com endereços, relatórios por período. No Firestore isso vira dado duplicado e junção feita no app. Postgres resolve com SQL: SuperDB ou Supabase.
• A conta ficou difícil de prever. O plano Blaze cobra por uso, então uma tela que lê demais aparece na fatura. Um plano mensal fixo, como os do SuperDB ou o Pro do Supabase, dá um número para colocar na planilha.
• A empresa precisa de nota fiscal brasileira. O SuperDB emite NFS-e a cada pagamento, no CPF ou no CNPJ do cadastro, nos planos pagos.
• Você quer rodar em servidor próprio. O Firebase não tem essa opção. PocketBase, Appwrite e Supabase têm.

O que muda ao sair do Firestore para Postgres

Trocar o Firebase pelo Supabase ou pelo SuperDB não é trocar um SDK por outro. É sair de documentos para tabelas. Vale saber onde está o trabalho antes de começar.

1. Coleções viram tabelas

Cada coleção vira uma tabela, e cada subcoleção vira uma tabela com chave estrangeira para a tabela pai. O dado que você duplicava para evitar consultas extras volta a morar num lugar só. É a parte que mais pede tempo de cabeça, e a que mais devolve depois.

2. Security Rules viram políticas de RLS

A regra “só o dono lê o próprio documento” vira uma política de Row Level Security em SQL. A ideia é a mesma, e ela vale para tudo que acessa o banco, não só para o SDK do app.

// Antes, no Firestore
allow read: if request.auth.uid == resource.data.userId;

-- Depois, no SuperDB
alter table pedidos enable row level security;
create policy "dono lê os pedidos" on pedidos
  for select to authenticated
  using (user_id = auth.uid());
grant select on pedidos to authenticated;

3. Consultas ficam mais curtas

O que no Firestore pedia duas leituras e uma junção no app sai numa chamada só, com a RLS valendo:

import { createClient } from '@superdb/client'

const db = createClient(
  'https://auth.superdb.com.br',
  process.env.NEXT_PUBLIC_SUPERDB_ANON_KEY,
  { project: 'meu_app' }
)

// Pedidos com os itens de cada um, do mais novo para o mais antigo
const { data } = await db
  .from('pedidos')
  .select('id, total, criado_em, itens(produto, quantidade)')
  .order('criado_em', { ascending: false })

4. Usuários migram no primeiro login

O Firebase guarda a senha numa variante própria do scrypt, que o SuperDB não confere. A saída é migrar cada pessoa no primeiro login, enquanto o Firebase ainda está no ar: o seu servidor confere a senha no Firebase e cria a conta no SuperDB com a mesma senha. Ninguém precisa redefinir nada. O passo a passo, com o código, está no guia de migração do Firebase.

5. Push continua funcionando

O SuperDB tem push para iPhone e Android: guarda os aparelhos, envia e registra o recibo. No Android, o FCM continua sendo o caminho, com a mesma conta de serviço; no iPhone, o envio vai direto pela Apple.

Para um app pequeno, com menos de cinco coleções, a conta costuma ficar entre um e dois dias de trabalho.

Quando cada alternativa faz sentido

Fique no Firebase se

O app depende de sincronização offline complexa no celular, usa Cloud Functions em muitos lugares ou vive de Analytics, Crashlytics e Remote Config. São coisas que o Firebase faz há anos, e que você teria de remontar em outro lugar.

Supabase

Para quem quer Postgres com o maior ecossistema: comunidade grande, Edge Functions, várias regiões (inclusive São Paulo) e opção de servidor próprio. A conta vem em dólar, então no cartão brasileiro a compra é internacional.

Appwrite

Para quem quer SDKs em várias linguagens e a opção de rodar na própria infraestrutura com Docker. No Cloud, não há região no Brasil.

PocketBase

Para quem quer um backend num executável só, com SQLite, rodando no próprio servidor. Backup, atualização e escala ficam por sua conta, e o projeto ainda está antes da versão 1.0.

SuperDB

Para quem quer Postgres com RLS e API REST automática, login com e-mail e senha, Google, GitHub, Apple, link mágico e MFA, e código pelo WhatsApp nos planos Pro e Escala. A conta é em real, com NFS-e, os dados ficam em São Paulo e o suporte é em português. O SDK @superdb/client segue os nomes do supabase-js. O SuperDB não tem Cloud Functions nem Edge Functions, não oferece servidor próprio e não tem sincronização offline como a do Firestore. Se algum desses pesa, escolha outro da lista.