El Problema que Nadie Te Dice de Firebase
Usé Firebase durante dos años en varios proyectos. Al principio es magia: autenticación lista, base de datos en tiempo real, hosting... todo funciona. Pero luego llega el momento en que necesitas algo un poco más complejo.
Quería filtrar documentos por múltiples campos, ordenar resultados de forma específica, y hacer agregaciones. Con Firestore, cada una de estas operaciones requiere índices compuestos. Y los índices, amigo, tienen un coste.
No es que Firebase sea caro *per se*. El problema es que los costes no son predecibles. Una query mal optimizada puede generar lecturas inesperadas. Y en Firestore, cada lectura cuenta, aunque sea un documento que luego descartas.
El Momento del Cambio
Tuve un proyecto con una tabla de usuarios que necesitaba filtrar por rol, estado y fecha de creación, ordenado por última actividad. En Firestore, eso requería un índice compuesto. Luego necesité otra combinación de filtros. Otro índice. Y otro más.
Eventualmente tenía 7 índices diferentes para una sola colección.
En ese momento me pregunté: ¿Por qué estoy pagando por esta complejidad cuando SQL resolvería esto en una línea?
```sql SELECT * FROM users WHERE role = 'admin' AND status = 'active' AND created_at > NOW() - INTERVAL '30 days' ORDER BY last_activity DESC; ```
Una query. Sin índices especiales. Sin configuración en la UI.
Supabase: PostgreSQL sin la Infraestructura
Supabase es esencialmente PostgreSQL hospedado con una UI bonita alrededor. Pero eso es exactamente lo que necesitaba.
Lo Que Ganaste al Cambiar
1. Queries SQL Reales
No hay abstracciones raras. Escribes SQL estándar. Si sabes SQL, sabes Supabase.
```javascript // Con Next.js y Supabase const { data, error } = await supabase .from('users') .select('*') .eq('role', 'admin') .eq('status', 'active') .gt('created_at', new Date(Date.now() - 30 * 24 * 60 * 60 * 1000).toISOString()) .order('last_activity', { ascending: false });
// Pero también puedes escribir SQL directo si lo necesitas const { data, error } = await supabase.rpc('get_active_admins'); ```
2. Joins Sin Penalización
En Firestore, los joins no existen realmente. Tienes que hacer múltiples queries y combinarlas en el cliente. En PostgreSQL, los joins son baratos y eficientes.
```sql SELECT u.id, u.name, COUNT(p.id) as post_count FROM users u LEFT JOIN posts p ON u.id = p.user_id WHERE u.status = 'active' GROUP BY u.id HAVING COUNT(p.id) > 5; ```
Una query. Hecho.
3. Transacciones Reales
Supabase soporta transacciones ACID. Si necesitas garantizar que múltiples operaciones se ejecutan juntas o ninguna, está resuelto.
4. Es Open Source
Supabase está construido sobre software open source. PostgreSQL es open source. Puedes correr Supabase en tu propio servidor si quieres. Eso significa que no estás atrapado en una plataforma propietaria.
Firebase es Google. Si Google cambia de opinión, cambias de opinión.
Lo Que Perdiste (Sí, Hay Tradeoffs)
No voy a fingir que Supabase es perfecto para todo.
Actualizaciones en Tiempo Real
Firestore tiene suscripciones en tiempo real que funcionan de forma nativa. Supabase tiene Realtime, pero funciona diferente. Es más limitado en algunos casos.
Para aplicaciones que necesitan actualizaciones en tiempo real ultra-frecuentes (como un editor colaborativo), Firebase sigue siendo más directo.
Escalabilidad Horizontal
PostgreSQL escala verticalmente muy bien. Pero si necesitas sharding automático, Firebase lo maneja mejor. Aunque siendo honesto, la mayoría de aplicaciones nunca llegan a ese punto.
Menos Magia
Firebase te da todo integrado. Supabase es más modular. Necesitas pensar en autenticación, storage, realtime por separado. Eso es más trabajo, pero también más control.
El Aspecto Económico (Sin Números Específicos)
En mi experiencia, Supabase es más asequible para aplicaciones con queries complejas. Firebase puede ser más económico si tu caso de uso es simple (lectura/escritura de documentos sin filtros complicados).
Lo importante es que con Supabase entiendes exactamente por qué pagas. Con Firebase, las sorpresas llegan cuando menos las esperas.
Mi Setup Actual
Ahora uso Supabase para prácticamente todo:
- Base de datos principal en PostgreSQL
- Autenticación con Supabase Auth
- Storage para archivos
- Realtime cuando lo necesito
- Funciones serverless para lógica compleja
Todo en un ecosistema coherente.
```typescript // Ejemplo real: Crear usuario con datos relacionados const createUserWithProfile = async (email: string, name: string) => { const { data, error } = await supabase .from('users') .insert([ { email, name, created_at: new Date().toISOString(), }, ]) .select();
if (error) throw error; return data[0]; }; ```
El Punto Real
No estoy diciendo que Firebase sea malo. Es excelente para ciertos casos de uso: MVPs rápidos, aplicaciones simples, cuando necesitas sacar algo a producción en horas.
Pero si tu aplicación crece, si necesitas queries sofisticadas, si quieres entender exactamente qué está pasando en tu base de datos... Supabase es el camino.
PostgreSQL lleva 30 años en producción. No es una moda. Es la herramienta que usan startups y empresas Fortune 500.
Supabase simplemente te da acceso a eso sin la complejidad de gestionar la infraestructura.
Takeaway
Elige herramientas basadas en lo que tu aplicación necesita, no en lo que es más cómodo inicialmente. Firebase es cómodo. Supabase es poderoso.
Para la mayoría de aplicaciones que crecen, el poder gana.
