Appwrite vs Firebase para Flutter: la comparativa honesta (features, costes, ops)
Sommaire
Al inicio de 2026, estuve en Flutter Lille, donde vi una conferencia de Jean-Baptiste Dujardin sobre Appwrite como backend para una app Flutter. Me dio ganas de plantear el tema con orden: ¿Es Appwrite una alternativa creíble a Firebase en 2026? Spoiler: sí… pero no por las mismas razones.
El objetivo aquí no es "vender" una tecnología. Es ayudarte a elegir en función de tu producto, tu equipo y tu relación con el self-host.
Comparativa "característica por característica"
La idea: separar el core backend (lo que hacen ambos) del pack de producto (donde Firebase tiene una ventaja clara).
1) Núcleo del backend (Auth / DB / Storage / Realtime / Functions / Messaging)
| Característica | Firebase | Appwrite | A saber en producción |
|---|---|---|---|
| Autenticación | Email/contraseña, teléfono, anónimo, proveedores "listos" (Google, Facebook, Apple, Twitter/X, GitHub, etc.) (Firebase) | Email/contraseña, SMS, Magic URL, Email OTP, OAuth2 (30+), anónimo, JWT, token personalizado, MFA (appwrite.io) | El SSO empresarial (SAML/OIDC) en Firebase requiere la actualización "Identity Platform". (Firebase) |
| BD | Cloud Firestore (NoSQL, tiempo real, sin conexión) (Firebase) | Appwrite Databases (colecciones/documentos + permisos) (appwrite.io) | El modelo de datos no es idéntico: piensa en "consultas + índices + reglas" antes de migrar. (Google Cloud Documentation) |
| Tiempo real | Listeners Firestore / sincronización (Firebase) | Tiempo real vía WebSocket (canales/eventos) (appwrite.io) | Appwrite: los cambios en las suscripciones pueden recrear la conexión → hay que gestionarlo en el lado de la gestión de estado. (appwrite.io) |
| Almacenamiento | Cloud Storage para Firebase (appwrite.io) | Storage + vistas previas/transformaciones de imágenes (Reddit) | En self-host: backend de almacenamiento + copias de seguridad = tu responsabilidad. (appwrite.io) |
| Funciones | Cloud Functions (infra gestionada) (Stack Overflow) | Functions con despliegues + activación/rollback (appwrite.io) | Atención a las diferencias entre Appwrite Cloud y self-host (runtimes/cotas). (appwrite.io) |
| Mensajería | FCM (push) (Firebase) | Push + Email + SMS unificados (appwrite.io) | Firebase cubre muy bien el push, Appwrite apunta a la "suite de comunicación". (Firebase) |
2) Pack de producto / crecimiento
| Funcionalidad "producto" | Firebase | Appwrite |
|---|---|---|
| Analytics | Google Analytics para Firebase (Firebase) | A completar vía herramienta de terceros |
| Crash reporting | Crashlytics (Firebase) | A completar vía herramienta de terceros |
| Feature flags / rollouts | Remote Config (banderas de características + despliegues) (Firebase) | A completar vía herramienta de terceros |
| A/B Testing | A/B Testing de Firebase (Firebase) | A completar vía herramienta de terceros |
| Hosting | Firebase Hosting (CDN, SSL, emparejamiento Functions/Cloud Run) (Firebase) | Appwrite Sites (alojamiento web) (appwrite.io) |
Si tu app es B2C y vives al ritmo de las experiencias / rollouts / correcciones de fallos, Firebase sigue siendo un "monolito de producto" muy difícil de superar.
Autenticación
Firebase Auth : rápido, integrado, y… muy "Google friendly"
Firebase Auth ofrece lo clásico: email/contraseña, teléfono (SMS), anónimo, autenticación personalizada, y proveedores federados.
En cuanto a proveedores, la doc de Firebase enumera los flujos/entradas para Google, Apple, Facebook, Twitter/X, GitHub, y otros según las plataformas (ej.: Play Games en Android).
Punto importante si trabajas en B2B/empresa: SAML y OIDC existen, pero a través de Firebase Authentication with Identity Platform (upgrade).
Appwrite Auth : más "plataforma", más opciones "passwordless"
Appwrite destaca: Magic URL, Email OTP, OAuth2 (30+ providers), MFA, JWT, custom token, etc.
Si quieres permitir a un usuario conectarse mediante varios métodos (Google + email/contraseña, por ejemplo), Appwrite gestiona la 'vinculación' mediante el concepto de Identities.
Mi opinión :
- Firebase es excelente para lanzar rápido, sobre todo si tu autenticación es "estándar móvil".
- Appwrite se vuelve muy atractivo si quieres impulsar el passwordless y mantener una lógica de plataforma (identities + permissions) sin reinventar la rueda.
Datos
Firestore tiene una ventaja muy concreta: persistencia sin conexión (cache + sync + last write wins). En cuanto a FlutterFire, incluso puedes configurar el comportamiento de la caché (tamaño, recolección de basura).
Appwrite puede ser en tiempo real, pero el enfoque "offline-first" suele ser más "a construir" en el cliente (según tu caso de uso y tu estrategia de sincronización).
Si tu app debe funcionar en el metro, en una obra, o en zonas sin cobertura: pon este punto en la parte superior de tu checklist.
DX & workflow : local, CI/CD, entornos
Firebase : el Emulator Suite es una arma
El Firebase Local Emulator Suite te permite probar localmente Firestore/Auth/Storage/Functions/etc., con una UI dedicada y posible integración CI.
Appwrite : "infra en Docker" + CLI para versionar la plataforma
Appwrite está pensado para ejecutarse dondequiera que Docker funcione. Y en cuanto al workflow, la CLI permite pull/push de recursos (ej.: esquemas BD/tablas) para sincronizar dev → preprod → prod.
En claro: Firebase te da una super sandbox local. Appwrite te ofrece una plataforma "versionable" de forma más natural.
Seguridad : Rules vs Permissions (y las trampas clásicas)
Firebase : Security Rules (potentes, pero requieren esfuerzo)
Las Firebase Security Rules aseguran Firestore/Realtime DB/Storage, con una sintaxis y condiciones muy expresivas. La trampa: es fácil hacer una regla demasiado permisiva, o una regla "justo suficiente" que falla en producción ante el primer caso límite.
Appwrite : permisos "whitelist" a nivel de recurso
Appwrite funciona con un sistema de permisos muy directo: autorizas a user / team / role a leer/escribir/eliminar un recurso.
Suele ser más fácil de razonar… pero aun así puedes perjudicarte con un any mal colocado.
Costes
Firebase : pay-as-you-go, así que "cuidado con la factura"
Firebase propone un calculador Blaze para estimar los costes. Y sobre todo: las alertas de presupuesto no impiden la facturación, solo alertan (matiz importante).
Appwrite : Cloud "por plan" + self-host "por infra + ops"
Appwrite Cloud muestra sus planes y explica la lógica de excedentes (cargas adicionales, límite de presupuesto). También han evolucionado el pricing (ej.: paso a un modelo "por proyecto", ajustes de ancho de banda).
Regla simple :
- Firebase te cobra el uso de forma detallada (y puede subir rápido si no lo controlas).
- Appwrite en self-host te hace pagar en "ops": VPS, almacenamiento, copias de seguridad, monitorización… y tu tiempo.
Appwrite en self-host
Si haces self-host de Appwrite, recuperas el control… y la responsabilidad.
- Installation : Appwrite apunta a una instalación con Docker, con prerrequisitos bastante estándar (2 CPU / 4GB RAM / Docker Compose).
- Updates : hay una doc "updates & migrations" y una migration tool.
- Backups : es tu responsabilidad (con recomendaciones RPO/RTO + pruebas de restauración).
La conferencia insistió en que "se mantiene bien" (Docker + migraciones). Estoy bastante de acuerdo… siempre que te tomes en serio las copias de seguridad/restauración desde el día 1.
Migración Firebase → Appwrite
Antes de migrar, recomiendo una checklist sencilla :
- Auth : proveedores utilizados, cuenta anónima, vinculación, SMS, SSO eventual.
- Datos : estructura, índices, consultas críticas, "offline behavior" esperado.
- Seguridad : reglas Firebase vs permisos Appwrite (modelo mental diferente).
- Funciones : triggers, secrets, rollback, workflow de despliegue.
- Pack de producto : analytics, crash reporting, feature flags, pruebas A/B : ¿con qué los reemplazas ?
Matriz de decisión
✅ Elegiría Firebase si…
- quiero un pack de producto completo (analytics/crash/flags/AB/push/hosting) sin ensamblar 6 servicios.
- priorizo el time-to-market y la tranquilidad infra.
- el enfoque offline-first es central (Firestore lo hace muy bien).
✅ Consideraría Appwrite si…
- quiero open-source + self-host (o Cloud) por razones de control/soberanía/costo.
- quiero una plataforma backend "todo en uno" en el core, sin un lock-in fuerte.
- estoy dispuesto a gestionar seriamente backups + upgrades + monitoring.
Conclusión
Firebase y Appwrite no juegan exactamente el mismo partido.
- Firebase gana cuando quieres lanzar + medir + iterar con una herramienta de producto muy madura.
- Appwrite gana cuando quieres recuperar el control sobre tu backend, sin volver a "me hago mi propio BaaS".
Comentarios
Cargando...