Sigues Llamando a Supabase "el Clon de Firebase". Ese Error de Categoría es el Que te Va a Costar los Datos de tus Usuarios
Piensas que Supabase es un clon de Firebase con esteroides. La narrativa lleva años instalada: "alternativa open-source a Firebase", "ideal para MVPs", "empieza en minutos sin pensar en el backend".
*El problema no es la etiqueta. El problema es que la etiqueta te hace ignorar la verdadera naturaleza del producto. *
Supabase no es una base de datos NoSQL con reglas declarativas como Firestore. Es una instancia completa de PostgreSQL real — la base de datos relacional más probada del planeta — vestida de serverless. Y la consecuencia práctica es brutal: el modelo de seguridad depende de ti, no de un JSON que escribes en un dashboard.
Firebase ponía sus security rules como una capa entre el cliente y los datos. Supabase baja la seguridad hasta SQL policies que viven en el propio esquema. Más auditable, más portable, sí.
Pero hay un matiz que la mayoría descubre demasiado tarde: *una tabla creada con RLS desactivado es legible y escribible por cualquier desconocido que tenga la anon key pública. *
Y la anon key es pública por diseño. Va en tu bundle de frontend.
Espera. Vamos al código antes de teorizar.
El Gotcha Que Nadie te Cuenta: Tu Tabla Sin Políticas es un Buffet Abierto
Crear una tabla y asumir que está protegida es el error más común en 2026.
Ahí mismo, sin tocar una línea más, cualquier persona con la anon key puede hacer GET /rest/v1/profiles y recibir el email de todos tus usuarios.
La anon key viaja en tu frontend. Está en las Network tabs de cualquiera que abra DevTools.
Ahora activa el RLS y repite la misma llamada:
*Esa diferencia — de exponerte a estar a salvo — es exactamente un `alter table`. *
Y el problema es que el estado por defecto de PostgreSQL es abierto. El RLS no se activa solo. Firebase al menos forzaba que escribieras sus reglas para que hubiera cualquier restricción. Supabase te da el poder total de PostgreSQL y asume que vas a ser disciplinado.
El 90% de los proyectos que empiezan un MVP con Supabase no lo son.
La Query Que te Salva el Culo
Puedes enumerar todas tus tablas sin RLS en una sola consulta:
Corre esa query en tu consola de Supabase ahora mismo.
Si devuelve algo, tienes datos al descubierto.
Por Qué el "Empieza Rápido, Migra Después" Está Invertido
Toda la doctrina de los MVPs con Firebase se resumía en una frase: "No pierdas tiempo en esquemas, migra cuando crezcas."
El problema de esa frase es que construías sobre NoSQL y el coste del cambio no era diferible — se pagaba en el peor momento posible, cuando ya tenías datos vivos, features encadenadas y clientes.
*Con Supabase la trayectoria está invertida: empiezas en PostgreSQL real y nunca necesitas migrar. *
Porque el esquema ES la API. PostgREST genera el endpoint REST directamente del esquema de la base de datos. Cada tabla, cada vista, cada columna se convierte en un endpoint. Cambias el esquema y el API cambia solo.
Esto colapsa una capa entera de CRUD.
En Firebase escribes handlers, validaciones, transformaciones. En Supabase escribes la migración y el backend se genera solo:
Con esas 25 líneas tienes: endpoints REST filtrados por usuario, insert limitado al dueño, y tipado generado casi automático con los clients de Supabase.
En Firestore tendrías que escribir las security rules JSON, configurar colecciones, y después construir la capa de servicios.
❌ Firebase: Rules JSON en consola + reglas de datos manuales + handlers por recurso.
✅ Supabase: RLS en SQL junto al esquema + PostgREST + un tier de CRUD que desaparece.
Pero ojo — esa inversión tiene un lado oscuro.
El Esquema es Tan Bueno Como Tu Disciplina
Si el esquema es la API, un esquema descuidado es una API descuidada.
En Firebase, un refactor de una ruta se aislaba en un handler. En Supabase, un cambio de esquema toca la base de datos directamente, y las policies incorrectas se propagan a cada petición.
Eso no es un argumento contra Supabase. Es un argumento contra la pereza arquitectónica.
Realtime: Donde la Base PostgreSQL Enseña las Costuras
Firebase tiene un Realtime Database pensado para fan-out de chats. Supabase hace realtime sobre la replicación lógica de PostgreSQL — el mismo mecanismo que usa la DB para mantener réplicas sincronizadas.
La ventaja es enorme: *el stream de eventos que alimenta tu UI es el mismo canal de escritura canónico de la base de datos. *
Pero hay que ser deliberados. Publicar toda la tabla en realtime es broadcasting innecesario. Supabase hace que el realtime sea opt-in por tabla via supabase_realtime publication — tú decides qué tabla emite eventos.
El trade-off es real: chat con fan-out muchos-a-muchos requiere diseño de canales cuidado. Firestore resuelve eso más fácilmente a escala pequeña, pero no te da SQL encima de los datos.
Depende de qué estés construyendo.
El Método RLS-First: Cinco Pasos para No Exponerte
Llamo a esto El Método RLS-First. No es opcional. Es lo único que separa un MVP de una brecha de datos.
Paso 1: Local, Nunca Nube Directa
Arranca con el CLI de Supabase o Docker. Diseña el esquema con migraciones desde el día uno.
La base de datos local es la fuente de verdad, no los clics en el dashboard. Cuando despliegas, las migraciones se aplican con supabase db push y todo queda versionado.
Paso 2: RLS como Preocupación de Primer Nivel
Activa RLS en cada tabla como parte de la migración inicial. Escribe las policies junto a la definición de la tabla. No en un "paso de seguridad" posterior.
Añade un check en CI que falle el build si hay alguna tabla con RLS desactivado. Es la version del linter pero para seguridad. Una línea en tu pipeline y el error deja de ser humano.
Paso 3: Diseña para la Anon Key Pública
Asume que el cliente puede leer todo lo que una policy permite. La service key jamás toca el frontend.
Para operaciones privilegiadas — incrementar un contador, operaciones administrativas — usa SECURITY DEFINER functions:
La función ejecuta con los privilegios del propietario, no del cliente. Eso te da una válvula de escape controlada sin abrir policies peligrosas.
Paso 4: Realtime Deliberado, No Automático
Suscríbete solo a las tablas que necesitan updates en vivo. Filtra los canales. No transmitas tablas enteras.
Rendimiento y privacidad van de la mano aquí: menos broadcast, menos superficie de ataque.
Paso 5: Auth, Storage y Realtime Integrados
Conecta auth.uid() en las policies de RLS. Los buckets de storage deben referenciar el mismo user id. Verifica el flujo completo — registro, subida, fetch — contra el stack local antes de desplegar.
¿Y el Lock-In? Hablemos de lo que es Realmente Pegajoso
Contesta esta objeción directamente porque la escucho cada semana.
El 80% de lo que usas en Supabase es PostgreSQL estándar. Puedes volcar la base (pg_dump) y emigrar a cualquier proveedor Postgres — Neon, RDS, tu propio servidor — en un día. Las policies RLS son SQL puro. Las migraciones son SQL puro. pgvector es una extensión estándar.
Las capas pegajosas de verdad son Auth y Edge Functions. Esas tienen APIs propietarias.
La válvula de escape: self-hosting con Docker o el CLI. Si un día odias la plataforma, te la montas tú. No es bonito, pero existe. Firebase no te ofrece siquiera esa opción.
Y sobre los outages y los límites de conexiones — hay que separar el FUD de 2022 de la realidad operativa. La gestión se ha estabilizado, pero PostgreSQL serverless tiene costuras reales: connection pooling, cold starts. El que te diga que son perfectos te está vendiendo algo.
Mi consejo: usa Supabase para el MVP, diseña las migrations como si fueran portátiles, y decide a escala si self-host o te quedas. *La disciplina de diseño te da la opción. La pereza te la quita. *
Veredicto 2026
Firebase no es basura. Sigue siendo la respuesta correcta para casos muy concretos: aplicaciones con patrones de datos extremadamente simples, equipos que no quieren tocar SQL bajo ninguna circunstancia.
Pero el 90% de los proyectos que elegían Firebase por comodidad acababan llorando en Stack Overflow cuando necesitaban un JOIN o una consulta analítica.
Supabase te da el poder de una base de datos real desde el día uno. Y con ese poder viene una responsabilidad que Firebase te quitaba de encima: *si no activas el RLS, tus datos están abiertos a internet. *
El impuesto oculto no es el lock-in. Es la línea de SQL que no escribiste.
Corre la query que te doy arriba. Si tu tabla no aparece, estás a salvo. Si aparece, tienes trabajo que hacer hoy mismo — no la semana que viene.
La buena noticia es que el arreglo es un comando:
Luego escribe tus policies. Y añade el check de CI.
Porque en 2026, el que ignora RLS no pierde el trabajo por falta de talento.
Lo pierde por haber expuesto la tabla de sus clientes a todo internet durante 18 meses sin saberlo.
Artículos relacionados
- Supabase vs Firebase 2026: Por Qué Tu Elección de Backend Define si tu App Escala o se Rompe
- Supabase vs Firebase 2026: Deja de Llamarlo "Firebase para PostgreSQL" — Es una Trampa para Frontend Developers
- Supabase vs Firebase 2026: Deja de Llamarlo "Firebase para PostgreSQL" — Es una Trampa para Frontend Developers
- Supabase vs Firebase 2026: El NoSQL fue un Desvío de 10 Años y Supabase es la Vuelta a la Cordura
- 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
