Comparativa de plataformas BaaS: análisis arquitectónico de Firebase, Supabase y Appwrite

Introducción: La evolución del Backend-as-a-Service

Las plataformas Backend-as-a-Service (BaaS) han evolucionado desde simples utilidades de sincronización para bases de datos móviles hasta convertirse en cimientos integrales para el desarrollo de software moderno. Al abstraer tareas rutinarias de infraestructura —como la gestión de identidades, el alojamiento de bases de datos, las autorizaciones en el cliente, el almacenamiento binario y el cómputo sin servidor (serverless compute)—, los servicios BaaS permiten que los equipos se concentren en las funcionalidades clave de su producto.

No obstante, la elección de un motor BaaS es una decisión arquitectónica determinante. Una migración tardía debida a una mala elección inicial conlleva una reescritura sustancial del código cliente, las directivas de seguridad y los esquemas de datos. Actualmente, las tres opciones principales representan enfoques radicalmente distintos:

1. Google Firebase: El pionero del BaaS en la nube administrada, estrechamente integrado con el ecosistema serverless propietario de Google Cloud Platform (GCP).
2. Supabase: La alternativa de código abierto a Firebase, construida directamente sobre el motor relacional PostgreSQL y respaldada por estándares SQL abiertos.
3. Appwrite: Una plataforma BaaS orientada a contenedores Docker y diseñada para el autoalojamiento (self-hosting), la modularidad y la soberanía absoluta de datos.

Esta guía ofrece una comparativa arquitectónica objetiva en seis dimensiones fundamentales: modelado de datos, autorización, comunicación en tiempo real, funciones serverless, experiencia de desarrollo y riesgos de dependencia del proveedor (vendor lock-in).

1. Visión general de la arquitectura y filosofías

┌─────────────────────────────────────────────────────────────────────────────┐
│                            PANORAMA DE LAS BAAS                             │
├─────────────────────┬───────────────────────────┬───────────────────────────┤
│   Google Firebase   │         Supabase          │         Appwrite          │
├─────────────────────┼───────────────────────────┼───────────────────────────┤
│ • Nube Propietaria  │ • Núcleo Open Source      │ • Núcleo Open Source      │
│ • Documentos NoSQL  │ • Relacional PostgreSQL   │ • Documentos / Clave-Valor│
│ • Totalmente Gestion│ • Nube y Autoalojable     │ • Contenedores Docker     │
│ • Ecosistema GCP    │ • SQL y Extensiones(pg_*) │ • Independencia de Nube   │
└─────────────────────┴───────────────────────────┴───────────────────────────┘

Firebase: El ecosistema cloud completamente administrado

Firebase funciona como una capa de abstracción sobre la infraestructura de Google Cloud. Su ventaja principal es la escalabilidad sin mantenimiento de servidores (Zero-Ops): no requiere aprovisionar instancias, redimensionar discos ni configurar grupos de conexiones. A cambio, sus motores de almacenamiento (Cloud Firestore y Realtime Database) son tecnologías propietarias de código cerrado.

Supabase: Rigor relacional con PostgreSQL de código abierto

Supabase prescinde de motores propietarios. Cada proyecto de Supabase es una instancia completa e independiente de PostgreSQL con permisos avanzados, equipada con PostgREST para generar APIs REST de forma automática, GoTrue para la autenticación y Realtime para la transmisión de eventos vía WebSockets. Quien domina SQL estándar ya domina Supabase.

Appwrite: Modularidad en contenedores y autoalojamiento soberano

Appwrite fue diseñado para ejecutarse en cualquier entorno donde funcione Docker. Agrupa autenticación, bases de datos, almacenamiento de archivos y ejecución de funciones en un conjunto de microservicios orquestados mediante Docker Compose. El autoalojamiento es un principio central de diseño, lo que resulta especialmente idóneo para proyectos sujetos a leyes estrictas de residencia de datos (RGPD).

2. Modelos de datos y capacidades de consulta

La discrepancia arquitectónica más relevante entre estas opciones radica en la forma de organizar y consultar los datos:

Ejemplos prácticos de consulta

Firestore (Búsqueda en documentos NoSQL)

Las consultas en Firestore exigen un cumplimiento estricto de las reglas de indexación. Los filtros de desigualdad sobre múltiples campos requieren la creación previa de índices compuestos:

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

// Requiere un índice compuesto generado en la Consola de Firebase
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 con cliente PostgREST)

Supabase permite aprovechar toda la expresividad del modelo relacional, incluyendo uniones anidadas en una única petición de red:

import { supabase } from './supabaseClient';

// Unión relacional: obtener facturas del inquilino junto con datos de clientes
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 sobre documentos)

Appwrite proporciona un constructor estructurado de consultas sobre colecciones:

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. Paradigmas de seguridad y control de acceso

Puesto que las aplicaciones web o móviles suelen comunicarse directamente con las APIs de las bases de datos BaaS, las reglas de autorización conforman el perímetro de seguridad esencial.

Firebase: Reglas de seguridad declarativas (Security Rules)

Firestore utiliza un lenguaje específico de dominio (DSL) ejecutado en los servidores perimetrales de Google:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /invoices/{invoiceId} {
      // Aislamiento del inquilino validado con el token de sesión
      allow read, write: if request.auth != null 
        && request.auth.token.tenant_id == resource.data.tenantId;
    }
  }
}

Supabase: Seguridad a nivel de fila (Row-Level Security - RLS)

Supabase delega el control de accesos a las directivas de seguridad nativas de PostgreSQL:

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

-- Política de aislamiento del inquilino utilizando el contexto JWT
CREATE POLICY tenant_isolation_policy ON invoices
  FOR ALL
  USING (
    tenant_id = (auth.jwt() -> 'app_metadata' ->> 'tenant_id')::uuid
  );

Ventaja: Al operar en el propio motor SQL, las directivas se aplican sin distinción a consultas originadas desde clientes, microservicios o sesiones de terminal con psql.

Appwrite: Listas de permisos y roles

Appwrite emplea un sistema directo de matrices de permisos asignados 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. Arquitectura de sincronización de datos en tiempo real

Cada solución utiliza un enfoque de red y un mecanismo de detección de cambios particular:

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

1. Firebase: Suscriptores de instantáneas (snapshot listeners) altamente optimizados. Cuando un documento cambia, el motor calcula la diferencia en datos y la transmite por un canal persistente. Muy eficiente en entornos móviles.
2. Supabase Realtime: Lee el registro de escritura anticipada (Write-Ahead Log - WAL) de PostgreSQL mediante la extensión pgoutput. Las transacciones confirmadas se publican a través de Phoenix Channels (WebSockets en Elixir) a los clientes suscritos.
3. Appwrite Realtime: Utiliza un clúster interno de Redis Pub/Sub enlazado a procesos de WebSockets. Cada mutación completada a través de la API se propaga inmediatamente a los sockets activos.

5. Computación serverless y funciones Edge

Las operaciones empresariales críticas (procesamiento de pagos, cifrado de archivos, integraciones con servicios externos) requieren un entorno serverless seguro:

• Firebase Cloud Functions: Se ejecuta en Google Cloud Functions (Node.js, Python), con integración nativa a eventos (onDocumentWritten, onUserCreated). Las funciones de segunda generación sobre Cloud Run optimizan la concurrencia.
• Supabase Edge Functions: Funciona sobre la red perimetral global mediante el runtime Deno. Ofrece arranques en frío inferiores a 50 ms, ejecución nativa de TypeScript y compatibilidad con estándares web (fetch, Request).
• Appwrite Functions: Se ejecutan en contenedores Docker independientes que admiten más de 15 entornos de desarrollo (Node.js, Python, PHP, Ruby, Dart, Go, Rust, Swift) y permiten instalar dependencias y utilidades binarias del sistema.

6. Autoalojamiento, portabilidad y dependencia de proveedor (Vendor Lock-in)

En proyectos donde la soberanía informática y las normativas de privacidad son obligatorias, Supabase y Appwrite constituyen las únicas opciones viables. En el caso de Supabase, incluso si se prescinde del servicio en la nube, se conserva una base de datos PostgreSQL lista para operar en servidores propios o en servicios gestionados como AWS RDS.

7. Matriz de decisión arquitectónica

                     ¿Requiere una base de datos relacional
                           con soporte para SQL y JOINs?
                                       │
                        ┌──────────────┴──────────────┐
                        │ SÍ                          │ NO
                        ▼                             ▼
               [Elija Supabase]              ¿El autoalojamiento
                                          es un requisito estricto?
                                                      │
                                       ┌──────────────┴──────────────┐
                                       │ SÍ                          │ NO
                                       ▼                             ▼
                               [Elija Appwrite]              [Elija Firebase]

Síntesis de recomendaciones

• Elija Supabase si: Desarrolla un SaaS empresarial complejo, una plataforma financiera o un sistema que requiera integridad relacional rigurosa, vistas complejas y extensiones como pgvector para inteligencia artificial.
• Elija Firebase si: Construye una aplicación móvil o un prototipo que deba lanzarse con rapidez, sin personal de operaciones dedicado y con integración directa con Google Analytics y Crashlytics.
• Elija Appwrite si: Su organización requiere mantener el control de sus servidores en nube privada y valora una interfaz REST/WebSocket uniforme en lugar de administrar directamente motores SQL.

Conclusión y lecturas recomendadas

Las plataformas BaaS se han consolidado como motores de producción de alta fiabilidad. Conocer de antemano los compromisos arquitectónicos relativos a la organización de los datos y a las fronteras de seguridad previene reestructuraciones costosas durante el ciclo de vida del software.

Guías de arquitectura relacionadas

• Para profundizar en edge computing y disparadores serverless, consulte Creación de backends serverless con BaaS.
• Para implementar flujos de sincronización colaborativa, lea Sincronización de datos en tiempo real con servicios backend.