El 90% de los que Elegís Firebase Acabáis Llorando en una Issue de Stack Overflow 6 Meses Después
No digo que Firebase sea malo. Digo que os venden una promesa que no puede cumplir.
"Empieza en minutos. Sin esquemas. Sin servidores. Sin migraciones."
*Suena genial hasta que necesitas hacer un JOIN. *
Ahí empieza la pesadilla. Desnormalizas datos. Escribes funciones de agregación que se rompen cuando crece tu app. Acabas con un cocktail de Firestore + una base de datos relacional aparte porque tu modelo de datos no encaja en documentos.
*La realidad es que el NoSQL fue un desvío de 10 años. *
Y Supabase es la vuelta a la cordura.
El NoSQL Hangover: Nos Vendieron Libertad y Nos Dieron Deuda Técnica
Entre 2012 y 2020, Firebase, MongoDB y DynamoDB dominaron el espacio del desarrollo web beginner-to-intermediate. El pitch era simple: "schemaless significa iteración más rápida". No defines esquemas. No escribes migraciones. Tiras JSON a la base de datos y listo.
*Lo que no os dijeron es que "schemaless" significa que implementáis la integridad relacional vosotros — en código de aplicación, mal, cada vez. *
El resultado es siempre el mismo:
❌ Firebase: Datos duplicados en 3 colecciones distintas porque no puedes hacer JOIN. Actualizas en un sitio, se te olvida en otro. Datos inconsistentes a las 2 semanas.
❌ Firebase: Tu app crece a 2 desarrolladores y ya nadie sabe qué campos existen en cada documento. No hay esquema, no hay tipos, no hay contrato.
❌ Firebase: Necesitas una relación muchos-a-muchos y acabas implementando un sistema de referencias manual que revienta en producción.
✅ Supabase/PostgreSQL: Defines tablas con claves foráneas. Los JOINs funcionan. Las migraciones son versionables. Y tu base de datos impone las reglas, no tu código de frontend.
El timing de Supabase fue casi perfecto. Lanzaron en 2020, justo cuando los desarrolladores de Firebase empezaban a encontrar los límites del modelo documental a escala. La industria colectivamente aprendió que "schemaless significa más rápido" solo si tu proyecto no dura más de 3 meses.
Para proyectos que quieren durar años, SQL nunca se fue. Solo lo ignorasteis porque montar PostgreSQL era un coñazo.
Supabase No es un "Firebase Killer". Es Algo Más Importante.
La prensa llama a Supabase el "Firebase killer". *Ese framing es incorrecto y os hace perder lo esencial. *
Firebase es excelente en lo que hace: prototipado ultrarrápido, offline-first, una SDK que te da CRUD en 3 líneas. Si estás haciendo un MVP de una semana, Firebase te gana.
Supabase no compite en facilidad de setup. Compite en *corrección de datos, poder relacional y mantenibilidad a largo plazo. *
Los números lo confirman:
- 2+ millones de developers activos mensuales a finales de 2023, creciendo 5x año contra año.
- 70.000+ estrellas en GitHub con licencia MIT — puedes auto-hostearlo o bifurcar la plataforma entera.
- Construido sobre PostgreSQL puro — no un motor NoSQL custom con capa SQL por encima. Postgres real.
La diferencia es arquitectónica, no cosmética. Firebase construyó su propio motor NoSQL propietario. Supabase dijo: "PostgreSQL ya resuelve esto — solo necesitamos una buena API alrededor."
La Ventaja que Nadie Ve: Self-Hosting y Cero Lock-In
Firebase es totalmente propietario. Tu código de frontend depende del SDK de Firebase. Tu lógica de negocio vive en Cloud Functions. Tu base de datos no se exporta a nada que no sea Firebase.
*El día que Firebase sube el precio o cambia su modelo, no tienes escapatoria. *
Supabase es MIT-licensed PostgreSQL. Esto significa:
- Empiezas en el tier cloud gratuito.
- Cuando creces, migras a auto-hosted.
- Si la plataforma no te gusta, bifurcas el repositorio.
Eso es libertad real. Para un technical founder que ya ha quemado 6 meses con Firebase y ha visto su factura dispararse, el self-hosting escape hatch es el factor decisivo.
PocketBase también es auto-hosteable, pero es single-binary con menos madurez. Supabase te da toda la infraestructura: auth, storage, real-time, Edge Functions, APIs auto-generadas. En un solo stack, con PostgreSQL debajo.
Real-Time vía Replicación, No Polling
Aquí está el detalle técnico que marca la diferencia.
La mayoría de soluciones BaaS con real-time usan WebSocket proxies que hacen polling a la base de datos o motores Pub/Sub custom.
*Supabase usa PostgreSQL logical replication slots. *
Los cambios se transmiten directamente desde el WAL (Write-Ahead Log) de Postgres. Esto significa:
- Consistencia transaccional: si un write está en una transacción, el evento real-time se dispara solo después del commit.
- Firebase real-time database: consistencia eventual. En apps colaborativas, eso genera bugs intermitentes que son un infierno de depurar.
En código, la diferencia es sutil pero poderosa:
El filtro en Supabase se evalúa en la base de datos antes de enviar el evento. En Firebase, traes documentos y filtras en cliente. Cuando tienes 10.000 usuarios en una sala, la diferencia es brutal.
El Problema Real del NoSQL: Te Obliga a Re-implementar SQL Tú Mismo
Esto es lo que nadie dice alto.
Cuando eliges Firebase Firestore para una app de chat con relaciones (usuarios → mensajes → canales → membresías), acabas haciendo esto:
¿Ves el problema? *Son N+1 queries. * Por cada mensaje, una query extra para traer el usuario. En una sala con 50 mensajes, son 51 lecturas.
En Supabase/PostgreSQL:
Un JOIN. Una query. Datos consistentes. Tipos generados automáticamente desde el esquema.
Firebase te fuerza a elegir entre desnormalizar (datos duplicados, inconsistencia) o hacer N+1 queries (rendimiento horrible). SQL te da relaciones sin sacrificar nada.
Y si necesitas campos flexibles — cosas tipo documento — PostgreSQL tiene JSONB. Lo mejor de ambos mundos: integridad relacional a nivel de fila + columnas flexibles tipo documento.
El Framework: El Patrón de 5 Pasos PostgreSQL-First
Si te convence el argumento pero no sabes por dónde empezar, aquí tienes el patrón exacto que uso en todos mis proyectos con Supabase.
1. Empieza con el esquema, no con el código
Al revés de Firebase (abres la consola y empiezas a tirar documentos), aquí defines tablas, relaciones y constraints primero.
Usa Supabase Studio o un fichero de migración:
*Parece más trabajo al principio. Se amortiza en la primera semana de desarrollo. *
2. Activa Row Level Security (RLS) en cada tabla
Este es el killer feature de Supabase. Las políticas de acceso viven en la base de datos, no repartidas en middleware:
Auth y acceso a datos en el mismo sitio. *Sin depender de que tu backend haga bien las comprobaciones. *
3. Genera tipos TypeScript desde el esquema
Esto te da tipos generados automáticamente desde PostgreSQL. *Zero gap de type safety entre base de datos y frontend. * Si cambias el esquema, los tipos se actualizan. Firebase no tiene nada equivalente.
4. Usa real-time subscriptions con criterio
No actives replicación en todas las tablas. Habilítala solo donde la necesites y filtra en servidor:
El filtro se evalúa en PostgreSQL vía las replication slots. No traes datos de más al cliente.
5. Migra la lógica de negocio a Edge Functions
Para lo que no debería ejecutarse en el cliente — webhooks, integración con Stripe, procesamiento — usa Supabase Edge Functions (Deno):
Auth checks via RLS. Lógica en Deno. Sin servidores que gestionar.
Las Dos Objeciones que Vale la Pena Responder
Objeción 1: "Firebase tiene mejor soporte offline. Supabase no funciona sin conexión."
*Es cierto hoy. * Las suscripciones real-time de Supabase dependen de conexión activa. Si tu app necesita ser offline-first pura, Firebase gana.
Pero: puedes poner RxDB con IndexedDB como capa de caché local sobre Supabase. Es un patrón realista que funciona. Y la mayoría de las apps no necesitan offline-first — necesitan que los datos sean correctos cuando hay conexión.
Objeción 2: "PostgreSQL no es bueno para datos jerárquicos o profundamente anidados."
*JSONB. * PostgreSQL tiene soporte nativo de JSONB desde 2016. Puedes tener columnas flexibles tipo documento dentro de filas relacionales. Es lo mejor de ambos mundos.
La SQL Renaissance en BaaS es Real
En 2026, el mercado lo ha confirmado. Supabase ha crecido 5x año contra año porque resuelve el problema real: los desarrolladores nunca quisieron abandonar SQL. Solo querían no tener que gestionar PostgreSQL ellos mismos.
*Firebase te prometió que no necesitabas SQL. Supabase te demuestra que siempre lo necesitaste. *
La diferencia no es técnica. Es filosófica. Firebase trata la base de datos como un detalle de implementación. Supabase trata la base de datos como el centro de tu arquitectura.
Y después de una década de NoSQL, centrar tu arquitectura en un motor relacional maduro, con 30 años de optimizaciones, integridad referencial y un query planner que sí sabe lo que hace — *eso no es volver atrás. Es dejar de perder el tiempo. *
Artículos relacionados
- Supabase vs Firebase 2026: The Decision That Will Multiply Your Deploy Speed
- Supabase vs Firebase 2026: Deja de Llamarlo "Firebase para PostgreSQL" — Es una Trampa para Frontend Developers
- Supabase vs Firebase 2026: Por Qué Tu Elección de Backend Define si tu App Escala o se Rompe
- Supabase Realtime: El Framework de Orquestación que Elimina la Necesidad de Redis y Message Brokers
- Supabase vs Firebase 2026: El NoSQL fue un Desvío de 10 Años y Supabase es la Vuelta a la Cordura
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
