Convex vs Supabase vs Firebase: Qual Escolher para o Teu SaaS

Convex vs Supabase vs Firebase: Qual Escolher para o Teu SaaS

TL;DR

• Firebase é o mais rápido para MVP, mas tens coupling forte com Google e custos imprevisíveis em escala. Convem para prototipagem, não para SaaS com margem.
• Supabase é PostgreSQL gerido com autenticação e realtime. Muito mais controlo, pricing linear, mas réplicas read são premium. Ideal para SaaS B2B com dados complexos.
• Convex é realtime database moderno, sem SQL, com pricing justo por computação. Menos maduro em 2024, mas o melhor trade-off entre simplicidade e controlo para produtos colaborativos em tempo real.
• A escolha não é técnica, é sobre margem, retenção de dados (lock-in), e velocidade de desenvolvimento. Três caminhos muito diferentes.

O Problema Real: Não é Tecnologia, é Economia

Quando um fundador me pergunta isto, normalmente já começou a construir em Firebase num fim de semana. Tem 2000 utilizadores, percebe que está preso, e questiona-se.

A verdade é que nenhuma destas três plataformas "ganha" simplesmente. O que varia é o teu negócio: fase, margem, complexidade de dados, volume, compromisso com controlo.

Firebase é a armadilha dourada. Googles documentação é impecável, o Firestore escala magicamente, a autenticação funciona sem configurar nada. Mas em produção, com 50k utilizadores activos e queries complexas, tens custos de leitura em produção que ninguém previu. Um cliente meu gastava €800/mês em reads porque o produto tinha denormalizações imprestáveis. Migrou, economizou €400 num mês. Isso é margem que desaparece.

Supabase resolve isto com transparência: PostgreSQL com preços claros. Sabes exactamente qual é o custo. Mas tens que arquitectar melhor (índices, replicação de dados), não é mágico.

Convex é a aposta técnica: menos maduro, mas construído para o problema certo (realtime, sem SQL dentistry, pricing por computação não por storage).

Firebase: Rápido até à Realidade

Firebase foi feito para protótipos. E funciona perfeitamente para isso.

O que funciona bem:

• Autenticação integrada: Google, Apple, anonymous, custom tokens. Tens isto em produção em 30 minutos.
• Firestore tem replicação global automática. Escreve numa região, lê noutras com latência sub-100ms (p99).
• Rules engine para autorização: é DSL integrada, sem backend extra.
• Integração com Google Cloud: logs, monitoring, Cloud Functions, nativo.

Custos reais (Firestore):

• Leitura: $0.06 por 100k docs (€0.055). Com queries complexas que fazem fan-out, explode rápido.
• Escrita: $0.18 por 100k (€0.165).
• Storage: $0.18 por GB/mês.
• Delete também custa leitura. Isto é um gotcha que vejo sempre: campos com valores nulos acumulam-se, e limpar é caro.

Exemplo concreto de problema: Um SaaS B2B com 10k utilizadores activos e 500M documentos históricos. Cada utilizador faz uma query que retorna 100 docs. São 1M leituras/dia só nisso. Em Firebase, são ~€180/mês só nessa query. Se duplicares a denormalizacao para performance, duplicas custos.

Armadilha crítica: Firestore não suporta JOINs. Tudo é denormalização. Isto significa dados duplicados, e cada atualização é uma escrita em 3 sítios. Custos crescem com complexidade, não com valor.

Supabase neste cenário: PostgreSQL com índices e JOINs normais. ~€30/mês em storage, queries são CPU-bound não IO-bound.

Quando Firebase funciona: Prototipagem, MVPs em 2-4 semanas, apps mobile com sincronização simples, chat em tempo real, produtos de consumo com pouco contexto transaccional.

Supabase: O Caminho Conservador (e Inteligente)

Supabase é "PostgreSQL + Autenticação + Realtime + REST API, tudo gerido".

PostgreSQL é estável, conheces o custo (compute + storage), e há 25 anos de patterns provados. Isto é importante numa SaaS: previsibilidade.

Pricing (Supabase Pro, 2024):

• €119/mês: 4GB storage, 1GB filestore, compute auto-scaling.
• Cada 1GB extra: €1.20/mês.
• Realtime: incluído, mas cada subscriber custa banda. Não é infinito.
• Database replicas (read-only): €750/mês extra por réplica.

Por que é mais barato em escala: PostgreSQL custa pelo que computas, não pelo que lês. Dez queries a 100ms cada é a mesma coisa que 1000 queries a 10ms. Firebase paga por cada leitura.

Um SaaS B2B típico com 20k utilizadores em Supabase:

• Pro plan: €119.
• 2 database replicas (Uma na UE, uma na US): €1500.
• Total: ~€1600/mês.

Mesmo SaaS em Firebase Blaze:

• 100M read operations/mês: ~€5500.
• Firestore storage (500GB): ~€90.
• Egress (dados para clientes): ~€300.
• Total: ~€5900/mês.

Isto não é especulação. Vi isto reproduzido três vezes.

O que precisas de fazer diferente:

• Arquitectar queries com JOINs inteligentes (não denormalizar tudo).
• Configurar índices. Firebase não pede isto, PostgreSQL exige.
• Gerenciar concorrência com RLS (Row Level Security) em Supabase ou trigger simples.
• Realtime em Supabase é websocket, logo taxa de heartbeat importa. Muitos clientes abertos = banda sai do orçamento.

Armadilha em Supabase: Realtime caro se não arquitectado. Se tens 5k utilizadores online a escutar a mesma tabela, dás ban às subscrições. Precisas de colunas estreitas, filtros client-side, ou caching Redis extra (mas agora tens outra infra).

Quando Supabase funciona: SaaS B2B com dados relacionados, precisão em consultas, billing baseado em uso, controlo de custos necessário, protecção de dados (GDPR compliance é mais simples, tudo em PostgreSQL teu), planos long-term sem surpresas.

Convex: O Futuro, Hoje, Mas com Asterisco

Convex nasceu há 3 anos. Backend-as-a-service sem SQL, focado em realtime e developer experience.

Arquitectura: cliente (JS/TS) conecta-se ao Convex backend. Defines funções (queries, mutations, actions). Convex gerencia sincronização, caching, permissões.

Não usas SQL. Usas JavaScript.

// Convex: query típica
export const getMessages = query({
  args: { roomId: v.id("rooms") },
  handler: async (ctx, { roomId }) => {
    return await ctx.db
      .query("messages")
      .filter(q => q.eq(q.field("roomId"), roomId))
      .order("_creationTime", "desc")
      .take(50);
  }
});

Comparar com Supabase:

SELECT * FROM messages WHERE room_id = $1 ORDER BY created_at DESC LIMIT 50;

Supabase é directo. Convex abstrai a query engine, caches de forma inteligente, sincroniza em realtime automático.

Pricing (Convex, 2024):

• Free: 1M function calls/mês, 1GB storage.
• Pro: $20/mês, depois $0.50 por 1M calls excess, $0.25 por GB storage excess.
• Database: JSONB de facto (tipo Firestore, mas com relações).

Um SaaS colaborativo típico (ex: Figma-like, Notion-like):

• 5k utilizadores.
• 100 function calls/utilizador/dia.
• Total: 500k calls/mês.
• Em Convex Pro: $20/mês.

Mesmo em Supabase Pro: €119/mês (mais caro, mas tens mais recursos).

O ganho real de Convex: Developer experience. Não escribes APIs REST. Definish handlers, e o cliente sincroniza automaticamente. Sem boilerplate de auth, sem middleware de permissões (usa patterns integrados).

Maturidade: Em 2024, Convex é estável em produção, mas não é Firebase/AWS em termos de ecosystem. Faltam integrações (Stripe, SendGrid precisam de custom actions). Documentação é boa, mas menos deep-dives que Firebase/Supabase.

Armadilha: Lock-in em Convex é real. Não há export de dados crus facilmente. Migrações significam reescrever queries inteiras. Em Firebase/Supabase exports em JSON/SQL é trivial.

Quando Convex funciona: Produtos colaborativos em realtime (Notion-like, Figma-like), equipas que codificam em TypeScript (não há alternativa em Python/Go), foco em velocidade de desenvolvimento sobre tudo, low-volume de dados (<5GB), budget limitado mas equipa técnica competente.

Comparação Lado a Lado: Números Concretos

A Decisão Real: Não é de Tecnologia

Aqui está a verdade que ninguém diz nos vídeos do YouTube: a escolha depende de três coisas.

1. Fase da empresa

MVP, seed, Series A diferem completamente.

• MVP (validação): Firebase é óptimo. Não gastas com infra, não têm tech debt, iteras rápido. Quando chegares a 10k users e os custos saltarem, migras para Supabase ou Convex (yes, é possível, mais em "Migrações").
• Seed (product-market fit): Supabase começa a fazer sentido. Tens receita, precisas de margem previsível, data integrity importa. Firebase cria problemas de custo aqui.
• Series A+: Convex para produtos realtime; Supabase para B2B tradicional. Firebase apenas se a lógica é muito simples ou global distribution é crítica.

2. Margem de SaaS

Isto é brutal: qual é o teu MRR target vs margem de produto?

• Se a margem target é 70%+, Firebase mata-te porque custos infra crescem com users, não com preço. Supabase/Convex deixam-te 90% margin com infra inteligente.
• Se a margem é 40-50%, Firebase talvez sobreviva se a lógica é simples (ex: app de listas simples).

3. Complexidade de dados

• Dados simples (chat, notificações, boilerplate): Firebase.
• Dados relacionados (billing, user accounts, audit logs, relatórios): Supabase.
• Dados realtime complexos (collab editing, multiplayer games): Convex.

Migrações: Sim, é Possível (e Mais Fácil que Pensas)

Firebase -> Supabase é feito em 2-3 sprints tipicamente.

Processo:

1. Export Firestore para JSON (firebase-export-cli ou custom script).
2. Transforma em CSV/SQL e importa para PostgreSQL.
3. Reescreve queries (Firestore DSL para SQL).
4. Migra realtime (Firebase listeners para Supabase realtime subscriptions).
5. Testa end-to-end (2 semanas).

Convex -> Supabase é mais difícil porque Convex não tem export de schema fácil. Precisas de mapear handlers para queries SQL manualmente.

Supabase -> Firebase é raro mas possível (SQL para Firestore denormalization).

Armadilhas Finais que Vi em Produção

1. Firebase com delete heavy: Cada delete é uma leitura. Se tens churn de dados (temp sessions, draft documents), gastas muito. Solução: soft-deletes ou TTL.

2. Supabase realtime sem filtros: Subscribes a tabelas inteiras, sync de 1000 rows quando precisas de 10. Taxa banda explode. Solução: filtros no subscribe, ou caching Redis.

3. Convex sem comprimento de nome em queries: Convex tem nome de função como index no cache. Nomes genéricos = cache colisões. Solução: nomes explícitos (getOrdersByUserId não getOrders).

4. Firebase auth em SaaS B2B: Firebase OAuth é consumer-first. SAML não existe. Se o cliente quer SAML/OIDC empresarial, não funciona. Precisa wrapper Auth0. Supabase isto faz melhor.

5. Supabase row-level security sem compreensão de permissões: RLS é poderoso mas a complexidade cresce. Uma regra com 3 condições AND/OR em 50k rows é lenta. Precisa índices. Muitos founders saltam isto.

Conclusão: O Meu Voto

Para um SaaS B2B novo em 2024:

Começa em Firebase se és prototipo puro (2-4 semanas, sem receita). Move para Supabase em 3-6 meses se acertaste na proposta de valor. Só vais para Convex se precisas de realtime complexo e a equipa domina TypeScript.

Se tens receita e complexidade de dados, Supabase é a escolha canónica. Custos previsíveis, dados teus, controlo total, comunidade robusta.

Se estás a construir multiplayer collaborative app (Figma-like), Convex é a resposta mais franca. Menos boilerplate, pricing justo, experiência dev superior.

Firebase é uma armadilha de conforto. Muito bom até deixar de sê-lo (sempre de forma inesperada).

Se estás a enfrentar um problema parecido, marca uma conversa em https://impact-origin.com/agendamento.