Supabase vs Firebase en 2026: Mi Experiencia Real en Producción Tras 1 Año
Comparativa honesta entre Supabase y Firebase después de usar ambos en producción. Costes reales, caídas, límites ocultos, vendor lock-in y cuál elegiría hoy para un SaaS.
Tabla de contenidos
Voy a ser directo: usé Firebase durante 2 años para un SaaS y lo migré a Supabase. No porque Firebase sea malo — es una herramienta brutal — sino porque me encontré con problemas que la documentación oficial no menciona y que ninguna IA te va a contar porque no ha pasado por la experiencia.
Este artículo no es la típica comparativa de “ambos son buenos dependiendo de tu caso de uso”. Es lo que me pasó a mí, con números reales.
El contexto: Qué construí con cada uno
Con Firebase (2023-2025): Un SaaS de gestión de reuniones con IA. ~2.000 usuarios activos, ~500 reuniones/día, almacenamiento de transcripciones.
Con Supabase (2025-2026): Migré ese mismo SaaS + lancé AtrapaClientes, un CRM con dashboard, webhooks y API pública.
Lo que nadie te cuenta de Firebase
La factura de Firestore es impredecible
Firebase cobra por número de lecturas de documentos, no por volumen de datos. Esto suena razonable hasta que haces una query que lee 500 documentos para mostrar una tabla con paginación.
Mi primer mes en producción real:
| Concepto | Estimado | Real |
|---|---|---|
| Lecturas Firestore | 1M | 4.2M |
| Escrituras Firestore | 200K | 180K |
| Storage | 2 GB | 1.8 GB |
| Factura | ~$15 | ~$47 |
¿Por qué 4x más lecturas de las esperadas? Porque cada vez que un listener de Firestore se reconecta (cambio de pestaña, pérdida de conexión), re-lee todos los documentos del snapshot. Con 500 usuarios activos, eso genera miles de lecturas fantasma que no ves en tu código.
Security Rules son un lenguaje de programación oculto
Las Firebase Security Rules parecen simples:
match /meetings/{meetingId} {
allow read: if request.auth.uid in resource.data.members;
}Hasta que necesitas validar datos complejos, hacer joins entre colecciones o verificar roles. Entonces te encuentras escribiendo un lenguaje de programación sin tipado, sin debugging y sin tests unitarios fáciles.
Después de romper producción 2 veces por una Security Rule mal escrita, dejé de confiar en ellas para lógica de negocio.
Vendor lock-in real
Migrar de Firestore no es “exportar un JSON”. El modelo de datos de Firestore (documentos anidados, subcollections, references) no tiene equivalente directo en SQL ni en MongoDB. Tuve que repensar toda la estructura de datos para migrar a PostgreSQL.
// Firestore: datos anidados en subcollections
/users/{userId}/meetings/{meetingId}/transcriptions/{transId}
// PostgreSQL: relaciones con foreign keys
users → meetings (user_id FK) → transcriptions (meeting_id FK)La migración de datos me llevó 3 semanas. Si lo hubiera empezado con PostgreSQL, habría sido 0.
Lo que nadie te cuenta de Supabase
PostgreSQL es increíble… pero necesitas saber SQL
Con Firebase, haces collection('users').where('role', '==', 'admin').get() y ya. Con Supabase tienes todo el poder de SQL, pero eso significa que necesitas saber SQL.
-- Esto que en Firestore es trivial...
-- collection('meetings').where('date', '>=', today).orderBy('date')
-- En Supabase requiere entender queries:
SELECT m.*, u.name as organizer_name
FROM meetings m
JOIN users u ON m.organizer_id = u.id
WHERE m.date >= CURRENT_DATE
ORDER BY m.date ASC
LIMIT 20 OFFSET 0;La ventaja: una vez que sabes SQL, puedes hacer cualquier cosa. Joins, aggregations, window functions, CTEs. Firestore no puede hacer un JOIN ni pagando.
Row Level Security (RLS) es mejor… pero más complejo
Las políticas RLS de Supabase son SQL estándar:
CREATE POLICY "Users can see their own meetings"
ON meetings
FOR SELECT
USING (auth.uid() = organizer_id OR auth.uid() = ANY(member_ids));Ventajas sobre Firebase Security Rules:
- SQL estándar (no un lenguaje inventado)
- Se pueden testear con queries normales
- Soportan joins y subqueries
Desventaja: si te olvidas de activar RLS en una tabla, todos los datos son públicos por defecto. Me pasó en desarrollo (gracias a Dios no en producción) con la tabla de api_keys. Supabase te avisa con un warning, pero si lo ignoras…
El tier gratuito se te queda corto rápido
| Recurso | Free tier | Mi uso real (mes 3) |
|---|---|---|
| Base de datos | 500 MB | 380 MB (bien) |
| Storage | 1 GB | 2.1 GB (superado) |
| Edge Functions | 500K invocaciones | 1.2M (superado) |
| Bandwidth | 2 GB | 4.5 GB (superado) |
| Coste Pro | $0 | $25 + $12 extras |
Con el plan Pro ($25/mes) tienes 8 GB de DB, 100 GB de storage y 2M edge functions. Para un SaaS con <5.000 usuarios es suficiente.
Realtime tiene límites
Supabase Realtime (equivalente a los listeners de Firestore) funciona bien para ~100 conexiones simultáneas. A partir de ahí necesitas el add-on de Realtime ($0.0015/mensaje). Firebase Realtime Database maneja mejor las conexiones masivas out-of-the-box.
Comparativa directa
| Aspecto | Firebase | Supabase | Ganador |
|---|---|---|---|
| Setup inicial | 5 min (consola web) | 5 min (consola web) | Empate |
| Curva de aprendizaje | Baja (NoSQL, SDK sencillo) | Media (SQL, RLS) | Firebase |
| Base de datos | Firestore (documento) | PostgreSQL (relacional) | Supabase |
| Auth | Excelente (muchos proveedores) | Muy bueno (GoTrue) | Firebase (por poco) |
| Storage | GCS integrado | S3-compatible | Empate |
| Realtime | Excelente | Bueno (límites) | Firebase |
| Edge Functions | Cloud Functions (Node) | Deno (edge) | Depende |
| Vendor lock-in | Alto | Bajo (SQL estándar) | Supabase |
| Precio predecible | No (lecturas variables) | Sí (plan fijo) | Supabase |
| SQL/Joins | No | Sí | Supabase |
| Self-hosting | No | Sí (Docker) | Supabase |
| Comunidad/Docs | Enorme (10+ años) | Grande y creciendo | Firebase |
Costes reales: Mes a mes para una app con ~2.000 usuarios
Firebase
| Mes | Lecturas | Storage | Functions | Total |
|---|---|---|---|---|
| 1 | $12 | $1 | $5 | $18 |
| 3 | $28 | $3 | $12 | $43 |
| 6 | $47 | $5 | $18 | $70 |
| 12 | $65 | $8 | $25 | $98 |
El problema: las lecturas crecen exponencialmente con los usuarios porque cada interacción genera más lecturas.
Supabase
| Mes | Plan | Extras | Total |
|---|---|---|---|
| 1 | Free | $0 | $0 |
| 3 | Pro $25 | $5 (storage) | $30 |
| 6 | Pro $25 | $10 | $35 |
| 12 | Pro $25 | $15 | $40 |
Supabase escala mejor en coste porque PostgreSQL no cobra por lecturas — cobra por almacenamiento y compute.
¿Cuál elegiría hoy?
Para un MVP que quiero lanzar en 1 semana: Firebase. El SDK es más rápido de integrar y la curva de aprendizaje es menor.
Para cualquier proyecto que vaya a durar más de 3 meses: Supabase. PostgreSQL es una base de datos seria que no te va a limitar cuando necesites hacer queries complejas, y el vendor lock-in es mínimo.
Para un SaaS con suscripciones y facturación: Supabase sin duda. Necesitas JOINs para reportes, transacciones ACID para pagos, y la capacidad de migrar si Supabase cierra o sube precios.
Si quieres ver cómo estructuré un SaaS con PostgreSQL, lee mi caso real de AtrapaClientes con NestJS y React.
Cómo migré de Firebase a Supabase
1. Auth (1 día)
# Exportar usuarios de Firebase
firebase auth:export users.json --format=json
# Script para importar a Supabase (simplificado)
node migrate-auth.jsFirebase permite exportar los hashes de contraseñas, así que los usuarios no tienen que hacer “olvidé mi contraseña” después de la migración.
2. Datos (2 semanas)
// Script de migración Firestore → PostgreSQL
const meetings = await db.collection('meetings').get();
for (const doc of meetings.docs) {
const data = doc.data();
await supabase.from('meetings').insert({
id: doc.id,
title: data.title,
organizer_id: data.organizerId,
date: data.date.toDate(),
// Flatten subcollections into related tables
member_ids: data.members || [],
});
// Migrar subcollection de transcripciones
const transcriptions = await doc.ref.collection('transcriptions').get();
for (const trans of transcriptions.docs) {
await supabase.from('transcriptions').insert({
meeting_id: doc.id,
content: trans.data().text,
created_at: trans.data().createdAt.toDate(),
});
}
}3. Storage (3 días)
# Descargar de Firebase Storage
gsutil -m cp -r gs://my-project.appspot.com/ ./backup/
# Subir a Supabase Storage
# (usé un script con el SDK de Supabase)4. Reescribir queries (1 semana)
De collection().where().get() a queries SQL con el SDK de Supabase. Esta fue la parte más lenta pero también la más satisfactoria — las queries SQL son más claras y potentes.
Conclusión honesta
Firebase es un producto excelente para prototipar rápido. Pero cuando tu app crece, la factura se descontrola, las Security Rules se vuelven inmanejables, y el vendor lock-in te atrapa.
Supabase requiere más conocimiento inicial (SQL, RLS), pero a cambio te da un stack estándar que puedes migrar a cualquier PostgreSQL del mundo si lo necesitas.
Mi regla: si el proyecto va a durar más de un sprint, empieza con Supabase. Tu yo del futuro te lo agradecerá.
Artículos relacionados
- Caso real: SaaS con NestJS y React — cómo construí AtrapaClientes sobre PostgreSQL
- Caso real: IA para reuniones con Gemini y Supabase — el proyecto que empecé en Firebase
- Deploy gratis con GitHub Actions — cómo desplegar sin depender de una sola plataforma
- Proteger tu API con JWT — auth hecha a mano vs BaaS
