Supabase puede convertir un prototipo en un producto rápidamente. Esa misma velocidad hace fácil olvidar que cada tabla, bucket y endpoint forma parte del modelo de seguridad.
RLS no es un detalle opcional
Row Level Security debe expresar quién puede leer, insertar, actualizar o borrar cada recurso. No basta con que la interfaz oculte un botón. Las políticas tienen que resistir peticiones construidas manualmente.
Autenticación no es autorización
Que un usuario tenga una sesión válida solo demuestra quién es. Todavía hay que decidir qué puede hacer. Prueba usuarios con permisos distintos y manipula IDs para comprobar que no existe acceso horizontal o vertical indebido.
Claves y frontend
Las claves diseñadas para el cliente deben tener un alcance compatible con ese uso. Los secretos de backend no deben llegar al navegador.
Storage
Un informe privado y una imagen pública no deberían compartir necesariamente el mismo modelo de acceso. Revisa buckets, subida, lectura, sustitución, borrado y URLs temporales.
Admin
Un panel administrativo no puede depender del hecho de que el botón sea invisible para el público. El servidor debe volver a comprobar sesión y rol antes de cada operación sensible.
Logs y observabilidad
Conserva suficiente información para responder qué ocurrió sin registrar datos innecesarios. Las operaciones destructivas deberían ser especialmente fáciles de investigar.
Cambios controlados
Las modificaciones de esquema deberían pasar por migraciones reproducibles. Los cambios manuales en producción son difíciles de reconstruir y pueden crear una diferencia entre la base real y el código.
Recuperación
Una copia solo ayuda si puede recuperarse. Define retención y, para datos importantes, prueba un escenario real de restauración.
Checklist mínima
- RLS activo y probado.
- Roles separados.
- Secretos fuera del cliente.
- Storage revisado.
- Operaciones administrativas protegidas.
- Logs suficientes.
- Índices para consultas críticas.
- Copias y recuperación conocidas.
- Migraciones controladas.
Cierre FMCP
La mejor revisión de Supabase es bastante aburrida: tabla por tabla, operación por operación y recurso por recurso. Cuando cada permiso tiene una razón concreta, el proyecto es mucho más fácil de mantener y auditar.
Una revisión completa de Supabase antes del lanzamiento
Supabase facilita construir rápidamente, pero la velocidad de desarrollo no elimina las decisiones de seguridad y operación. Una revisión útil debe mirar datos, identidad, Storage, funciones, logs y recuperación.
Tablas y Row Level Security
Empieza por clasificar las tablas. ¿Cuáles son públicas? ¿Cuáles pertenecen a un usuario? ¿Cuáles contienen información administrativa? Después revisa las políticas de RLS con identidades diferentes. No basta con que un usuario legítimo pueda leer su información; también hay que comprobar que otro usuario no pueda obtenerla cambiando un identificador.
Claves y secretos
Las claves públicas pueden aparecer en el navegador cuando el producto está diseñado para utilizarlas. Las credenciales administrativas y secretos de terceros no. Separa claramente lo que puede conocer el cliente de lo que debe permanecer en el servidor.
Storage
Define bucket por bucket si el contenido es público o privado. Revisa subida, lectura, sustitución y borrado. Para archivos privados, comprueba que una URL no pueda convertirse en acceso permanente accidentalmente.
Funciones con privilegios
Una función con permisos elevados debería recibir solo los datos que necesita y verificar quién la ejecuta. Cuanto más poder tiene una función, más importante es que el límite de autorización esté en el servidor y pueda probarse.
Pruebas de acceso
Crea dos usuarios de prueba y ejecuta lecturas, actualizaciones y eliminaciones cruzadas. Haz también las pruebas desde peticiones directas. La interfaz puede ocultar errores de autorización que una petición manual revela inmediatamente.
Copias y recuperación
No consideres una copia de seguridad suficiente hasta saber cómo se restauraría. Define frecuencia, retención y qué cambios serían recuperables. Cuando el proyecto sea importante, realiza una prueba de restauración para descubrir problemas antes de una emergencia.
Migraciones
Los cambios de esquema deberían quedar versionados y ser reproducibles. Evita que una modificación manual realizada en producción se convierta en un estado que no existe en Git. La trazabilidad es especialmente importante cuando hay varias personas trabajando en el proyecto.
Rendimiento
Revisa consultas frecuentes, índices y tamaño de las respuestas. Un endpoint que devuelve más columnas de las necesarias puede funcionar durante el prototipo y generar coste cuando aumente el tráfico.
Observabilidad
Define qué eventos deben quedar registrados: cambios administrativos, fallos de autenticación, operaciones sensibles y errores. Evita almacenar información sensible innecesaria, pero conserva lo suficiente para reconstruir una incidencia.
El panel administrativo
La protección no termina porque una ruta esté detrás de una pantalla de login. El backend debe comprobar sesión, rol y pertenencia del recurso. Un panel de administración bien diseñado trata cada operación como una frontera de confianza.
Checklist de producción
- RLS probado con múltiples identidades;
- claves públicas y secretos separados;
- buckets correctamente clasificados;
- funciones privilegiadas revisadas;
- logs útiles y sin exceso de datos sensibles;
- índices en consultas críticas;
- migraciones versionadas;
- estrategia de copias y restauración probada;
- asesores de seguridad y rendimiento revisados.
Cierre FMCP
Una configuración de Supabase es buena cuando puedes explicar por qué cada usuario puede hacer cada cosa y cómo recuperar el sistema cuando algo sale mal. La seguridad no debe ser una colección de casillas; debe ser un comportamiento comprobable.
Supabase en producción: la diferencia entre una base que funciona y una base que se puede operar
Supabase permite construir rápidamente sobre PostgreSQL, pero la velocidad de desarrollo no elimina las decisiones de producción. Cuando aparecen usuarios reales, la base de datos pasa a ser parte crítica del producto: permisos, copias, índices, Storage, observabilidad y migraciones dejan de ser detalles secundarios.
Empieza por el modelo de datos
Cada tabla debe tener una responsabilidad clara y relaciones coherentes. Los identificadores, fechas, estados y referencias deben ser consistentes. Un esquema ambiguo suele terminar en consultas complejas y lógica duplicada en el frontend.
RLS no es un interruptor mágico
Row Level Security debe expresar quién puede leer o modificar cada fila. Una aplicación multiusuario no puede limitarse a esconder botones en la interfaz. La autorización debe comprobarse en la base o en el servidor que la protege. También conviene recordar que una política de UPDATE necesita un SELECT policy compatible para que la operación funcione correctamente.
Storage como sistema de archivos del producto
Las imágenes, vídeos y documentos grandes deben vivir en Storage, no mezclados innecesariamente con las filas de la base. Supabase documenta Storage como un sistema específico para archivos, con buckets, control de acceso y CDN; también recomienda elegir una política de acceso adecuada para cada bucket.
Índices y consultas
Una aplicación pequeña puede funcionar sin pensar demasiado en índices. A medida que crece, las columnas utilizadas para filtros, relaciones y ordenaciones frecuentes necesitan atención. El objetivo no es llenar todas las tablas de índices, sino medir consultas reales y añadir los que reduzcan trabajo relevante.
Migraciones y reversibilidad
Todo cambio estructural debe poder reproducirse. Una migración versionada permite saber qué ocurrió, en qué orden y cómo reconstruir un entorno. Para cambios delicados conviene separar esquema y datos, probar en una base de desarrollo y tener una estrategia de vuelta atrás.
Observabilidad
No basta con saber que PostgreSQL responde. Hay que observar consultas lentas, errores, crecimiento de tablas, uso de Storage y operaciones administrativas. La métrica más útil suele ser la que ayuda a explicar por qué una experiencia de usuario empeoró.
Checklist de salida
Antes de producción: RLS probado con varios roles, Storage revisado, índices para consultas críticas, migraciones versionadas, copias verificadas, secretos fuera del cliente, límites definidos y un procedimiento de recuperación probado.
La ventaja real de Supabase no está solo en acelerar un MVP. Está en poder llevarlo a producción manteniendo datos, permisos y operaciones bajo control.
Supabase: cómo diseñar un Storage que no se convierta en un cajón de sastre
Un bucket limpio tiene convenciones de nombres, separación por tipo de activo y reglas de acceso claras. Las imágenes públicas de un blog no deberían compartir necesariamente la misma política que documentos privados de clientes.
Convenciones que evitan problemas
Usar rutas estables por entidad facilita migraciones y limpieza. Un patrón como blog/{slug}/cover-v2.webp hace más sencillo identificar qué recurso pertenece a qué contenido que una colección de UUIDs sin contexto.
CDN y caché
Supabase Storage ofrece CDN global y transformación de imágenes, por lo que tiene sentido aprovechar rutas de assets estables y cacheables. La documentación actual recomienda además evitar sobrescrituras innecesarias cuando se quiere minimizar la propagación de contenido antiguo en los nodos de CDN.
Regla práctica
Storage debe encargarse del archivo; PostgreSQL debe conservar la relación y los metadatos. Separar esas responsabilidades simplifica el sistema y facilita futuras migraciones.
Copias, restauración y pruebas: tres cosas distintas
Tener un backup no demuestra que puedas recuperarte. Una copia puede estar dañada, incompleta o desactualizada. Por eso una estrategia de producción debe separar copia, restauración y prueba de restauración.
Definir qué significa recuperar
Antes de una incidencia hay que decidir qué datos son críticos, cuánto tiempo de pérdida es aceptable y cuánto tiempo puede permanecer el servicio degradado. Esa definición permite diseñar backups con un objetivo real.
Probar sin miedo
La restauración debe practicarse en un entorno separado. El objetivo es demostrar que los archivos existen, que el esquema coincide y que la aplicación puede arrancar usando los datos restaurados. Una copia nunca probada es una suposición.
Evitar sobrescrituras innecesarias
Para assets públicos, las rutas versionadas son especialmente útiles. Supabase indica que sobrescribir archivos puede mantener contenido antiguo en nodos de CDN durante cierto tiempo; crear una ruta nueva reduce ese problema.
FMCP / MEDIA
