Comparativo de Plataformas BaaS: Avaliação Arquitetural de Firebase, Supabase e Appwrite

Introdução: A Evolução do Backend-as-a-Service

As plataformas Backend-as-a-Service (BaaS) evoluíram de utilitários de sincronização para bancos de dados móveis para bases completas de desenvolvimento de aplicações modernas. Ao abstrair rotinas de infraestrutura — gestão de autenticação, hospedagem de bancos de dados, regras de autorização cliente, armazenamento de binários e computação serverless —, as soluções BaaS liberam os times de engenharia para criar diferenciais de produto.

Contudo, a escolha do mecanismo BaaS é um compromisso arquitetural definitivo. Migrar no futuro a partir de uma plataforma inadequada exige reescrever camadas inteiras de código cliente, lógica de segurança e modelagens de dados. Atualmente, as três opções predominantes representam filosofias bem distintas:

1. Google Firebase: O pioneiro do BaaS em nuvem gerenciada, fortemente atrelado ao ecossistema serverless proprietário do Google Cloud Platform (GCP).
2. Supabase: A alternativa open source ao Firebase construída sobre o motor relacional PostgreSQL, adotando padrões SQL abertos e ferramentas consagradas.
3. Appwrite: Plataforma BaaS open source desenhada para auto-hospedagem (self-hosting), microsserviços em contêineres Docker e independência total de infraestrutura.

Este guia oferece uma comparação técnica objetiva em seis dimensões decisivas: modelagem de dados, autorização, comunicação em tempo real, funções serverless, experiência do desenvolvedor e riscos de aprisionamento tecnológico (vendor lock-in).

1. Visão Geral da Arquitetura e Filosofias

┌─────────────────────────────────────────────────────────────────────────────┐
│                            CENÁRIO DAS BAAS                                 │
├─────────────────────┬───────────────────────────┬───────────────────────────┤
│   Google Firebase   │         Supabase          │         Appwrite          │
├─────────────────────┼───────────────────────────┼───────────────────────────┤
│ • Nuvem Proprietária│ • Núcleo Open Source      │ • Núcleo Open Source      │
│ • Documentos NoSQL  │ • Relacional PostgreSQL   │ • Documentos / Chave-Valor│
│ • 100% Gerenciado   │ • Nuvem ou Auto-hospedado │ • Contêineres Docker      │
│ • Ecossistema GCP   │ • SQL e extensões pg_*    │ • Independência de Nuvem  │
└─────────────────────┴───────────────────────────┴───────────────────────────┘

Firebase: O Ecossistema em Nuvem Totalmente Gerenciado

O Firebase funciona como uma camada de abstração sobre o Google Cloud. Seu foco é a escalabilidade sem gestão de servidores (Zero-Ops): não há configuração de instâncias, dimensionamento de discos ou pools de conexão. Como contrapartida, seus bancos (Cloud Firestore e Realtime Database) são tecnologias proprietárias de código fechado.

Supabase: Rigor Relacional com PostgreSQL Open Source

O Supabase descarta motores proprietários de dados. Cada projeto é uma instância dedicada de PostgreSQL com privilégios de superusuário, trazendo PostgREST para geração automática de APIs REST, GoTrue para autenticação e Realtime para transmissão via WebSockets. Se você domina SQL padrão, já domina o Supabase.

Appwrite: Modularidade em Contêineres e Auto-hospedagem

O Appwrite foi arquitetado para rodar em qualquer ambiente compatível com Docker. Ele reúne serviços de autenticação, banco de dados, armazenamento e ambientes de execução de funções em uma malha orquestrada via Docker Compose. A auto-hospedagem é uma prioridade nativa, o que o torna ideal para projetos sujeitos a rigorosas leis de soberania de dados (LGPD, GDPR).

2. Modelos de Dados e Recursos de Consulta

A divergência mais significativa entre as plataformas está na forma como os dados são organizados e consultados:

Exemplos Práticos de Consultas

Firestore (Busca de Documentos NoSQL)

Consultas no Firestore obedecem a regras rígidas de índices. Filtros com operadores de desigualdade em múltiplos campos requerem a criação prévia de índices compostos:

import { collection, query, where, getDocs } from 'firebase/firestore';

// Exige um índice composto configurado no Firebase Console
const q = query(
  collection(db, 'invoices'),
  where('tenantId', '==', 'tenant_123'),
  where('status', '==', 'unpaid')
);

const snapshot = await getDocs(q);
const invoices = snapshot.docs.map(doc => ({ id: doc.id, ...doc.data() }));

Supabase (SQL Relacional via Cliente PostgREST)

O Supabase permite realizar consultas relacionais expressivas, incluindo junções aninhadas em uma única requisição:

import { supabase } from './supabaseClient';

// Junção relacional: buscar faturas do inquilino com dados do cliente
const { data, error } = await supabase
  .from('invoices')
  .select(`
    id,
    amount_cents,
    status,
    customers (
      name,
      email
    )
  `)
  .eq('tenant_id', 'tenant_123')
  .eq('status', 'unpaid');

Appwrite (Motor de Consultas em Coleções de Documentos)

O Appwrite oferece um construtor estruturado e seguro de consultas programáticas:

import { Client, Databases, Query } from 'appwrite';

const databases = new Databases(client);

const response = await databases.listDocuments(
  'production_db',
  'invoices_col',
  [
    Query.equal('tenantId', 'tenant_123'),
    Query.equal('status', 'unpaid'),
    Query.limit(50)
  ]
);

3. Modelos de Segurança e Regras de Acesso

Como as aplicações cliente frequentemente conectam-se diretamente às APIs dos bancos de dados, as regras de autorização constituem a barreira primária de proteção.

Firebase: Regras de Segurança Declarativas (Security Rules)

O Firestore utiliza uma linguagem específica de domínio (DSL) avaliada nos servidores da Google:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /invoices/{invoiceId} {
      // Isolamento multi-inquilino baseado no token de autenticação
      allow read, write: if request.auth != null 
        && request.auth.token.tenant_id == resource.data.tenantId;
    }
  }
}

Supabase: Segurança em Nível de Linha (Row-Level Security - RLS)

O Supabase delega toda a autorização às políticas nativas do motor do PostgreSQL:

-- Ativar Row Level Security
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

-- Política de isolamento extraindo contexto da sessão JWT
CREATE POLICY tenant_isolation_policy ON invoices
  FOR ALL
  USING (
    tenant_id = (auth.jwt() -> 'app_metadata' ->> 'tenant_id')::uuid
  );

Vantagem: As regras são políticas SQL convencionais, aplicadas universalmente quer as requisições venham de SDKs clientes, microsserviços ou sessões diretas do psql.

Appwrite: Listas de Permissões e Perfis

O Appwrite adota um modelo direto de matrizes de permissões anexadas diretamente a cada documento:

import { Permission, Role } from 'appwrite';

await databases.createDocument(
  'production_db',
  'invoices_col',
  'unique()',
  { tenantId: 'tenant_123', amount: 5000 },
  [
    Permission.read(Role.team('team_123', 'admin')),
    Permission.update(Role.team('team_123', 'finance')),
    Permission.delete(Role.team('team_123', 'owner')),
  ]
);

4. Arquitetura de Sincronização em Tempo Real

Cada plataforma implementa protocolos de transporte e detecção de alterações distintos:

[Firebase] Cliente ◄──── Fluxo Bidirecional gRPC / HTTP ───► [Motor Firestore]
[Supabase] Cliente ◄──── WebSocket (wal2json / pgoutput) ──► [Motor WAL PostgreSQL]
[Appwrite] Cliente ◄──── WebSocket (Redis Pub/Sub) ────────► [Gateway Appwrite Realtime]

1. Firebase: Ouvintes de snapshots altamente otimizados. Quando um documento sofre mutação, o Firestore calcula a diferença de dados e a envia por um canal contínuo. Baixa latência comprovada em redes móveis.
2. Supabase Realtime: Monitora o log de escrita antecipada (Write-Ahead Log - WAL) do PostgreSQL usando o plugin pgoutput. Transações confirmadas são transmitidas via Phoenix Channels (WebSockets em Elixir).
3. Appwrite Realtime: Emprega um cluster interno Redis Pub/Sub com workers de WebSockets. Cada mutação concluída pela API emite eventos instantâneos para os sockets registrados.

5. Computação Serverless e Funções de Borda (Edge)

Lógicas de negócio complexas e sigilosas exigem execução serverless isolada:

• Firebase Cloud Functions: Roda sobre o Google Cloud Functions (Node.js, Python), com integrações nativas de eventos (onDocumentWritten, onUserCreated). Funções V2 em Cloud Run oferecem maior suporte à concorrência.
• Supabase Edge Functions: Baseadas no ambiente Deno distribuído na rede edge global. Tempo de inicialização a frio inferior a 50 ms, suporte direto a TypeScript e uso de APIs Web padronizadas (fetch, Request).
• Appwrite Functions: Executadas em contêineres Docker isolados com mais de 15 ambientes disponíveis (Node.js, Python, PHP, Ruby, Dart, Go, Rust, Swift) e liberdade para compilar dependências binárias do sistema operacional.

6. Auto-hospedagem, Portabilidade e Bloqueio Tecnológico (Vendor Lock-in)

Quando a soberania e a localização estrita de dados forem exigências regulatórias, Supabase e Appwrite são as alternativas ideais. No Supabase, mesmo que encerre o serviço de nuvem, sua empresa retém um banco PostgreSQL convencional e pronto para ser executado em infraestruturas próprias.

7. Matriz de Decisão Arquitetural

                      Você precisa de um banco relacional
                            com suporte a SQL e JOINs?
                                       │
                        ┌──────────────┴──────────────┐
                        │ SIM                         │ NÃO
                        ▼                             ▼
               [Escolha Supabase]            A auto-hospedagem é
                                            requisito indispensável?
                                                      │
                                       ┌──────────────┴──────────────┐
                                       │ SIM                         │ NÃO
                                       ▼                             ▼
                               [Escolha Appwrite]            [Escolha Firebase]

Resumo das Recomendações

• Escolha Supabase: Se você está desenvolvendo um software SaaS B2B, sistema financeiro ou qualquer aplicação que exija integridade referencial, consultas complexas e extensões como pgvector para inteligência artificial.
• Escolha Firebase: Se o seu foco é lançar um MVP móvel com velocidade máxima, sem equipe de operações e com integração imediata às ferramentas da Google (Analytics, Crashlytics).
• Escolha Appwrite: Se a sua organização precisa de posse absoluta sobre os servidores de dados em nuvem privada e prefere uma API REST/WebSocket moderna sem ter que administrar bancos relacionais diretamente.

Conclusão e Leituras Recomendadas

As plataformas BaaS representam hoje estruturas arquiteturais robustas e preparadas para grandes cargas de produção. Avaliar previamente as diferenças de modelagem e segurança garante que o seu projeto cresça sem a necessidade de migrações traumáticas no futuro.

Guias de Arquitetura Relacionados

• Para se aprofundar em gatilhos e edge computing, veja Construindo Backends Serverless com BaaS.
• Para sincronizar dados colaborativos em tempo real, leia Sincronização de Dados em Tempo Real com Serviços Backend.