Cuando trabajas con Supabase, llega un punto en el que necesitas que tus imágenes y tus datos vivan juntos sin estorbarse. Aquí entra la relación entre Supabase Storage y la base de datos: el storage guarda los archivos y la base de datos guarda la URL que apunta a ellos. Ese vínculo es el que permite que un feed, un perfil o un detalle de post muestre imágenes reales en tu aplicación.

Por qué guardar solo la URL y no el archivo en la base de datos

La lógica detrás de este patrón es simple: cada herramienta hace lo que sabe hacer mejor. Storage se encarga de los binarios pesados y la base de datos se encarga de la metadata estructurada como autor, caption, fecha o likes.

Cuando subes una imagen a un bucket público, Supabase te devuelve una URL pública que cualquier navegador puede abrir sin autenticación. Esa URL la guardas en una columna, normalmente llamada image_url, dentro de tu tabla de posts. Esa columna se convierte en el puente entre el registro y el archivo físico.

¿Por qué no guardar la imagen directo en la base de datos? Porque sobrecargas la base con archivos binarios y pierdes el CDN, el cacheo y el control de tipo de contenido que ya te da el storage.

Este enfoque tiene cuatro ventajas concretas:

• No saturas la base de datos con blobs pesados.
• Aprovechas la infraestructura optimizada del storage con CDN y cacheo.
• Controlas permisos con políticas de Row-Level Security sobre el storage, separadas de las reglas de la base de datos.
• Si migras los assets a otro servicio, solo actualizas la URL, sin reescribir registros ni mover binarios.

Cómo es el flujo correcto al subir una imagen desde el frontend

El orden importa, y siempre es el mismo. Cuando un usuario sube una foto en una app tipo SuplatziGram, el frontend ejecuta tres pasos en secuencia.

1. Sube el archivo al bucket de Storage.
2. Obtiene la URL pública que devuelve el storage.
3. Guarda esa URL en el campo image_url (o como lo hayas nombrado) dentro de la tabla de posts.

Después, cuando tu frontend pide los posts, recibe los datos y la URL juntos. Con eso renderiza la imagen directamente en la interfaz, sin pasos intermedios.

¿Qué pasa si el bucket no es público? Necesitas usar Signed URLs, que son enlaces temporales firmados que permiten acceder al archivo sin exponerlo abiertamente.

Qué es una Signed URL y cuándo conviene

Una Signed URL es un enlace con firma temporal que da acceso a un archivo privado por un tiempo limitado. Te sirve cuando no quieres que el contenido sea visible para cualquiera con el link, por ejemplo, documentos o imágenes de perfiles privados.

Qué debes revisar para que la relación funcione sin errores

Hay detalles pequeños que rompen el flujo si no los cuidas desde el inicio. Vale la pena tenerlos presentes antes de programar la lógica de subida.

• Configura el bucket como público si quieres que las imágenes se vean sin autenticación. Si no, usa Signed URLs.
• Guarda siempre la URL exacta que genera el storage. Nada de rutas relativas ni nombres de archivo sueltos sin contexto.
• Revisa las políticas de Row-Level Security para que permitan la lectura pública o el uso de Signed URLs.
• Mantén el orden del flujo: primero storage, después URL, después base de datos.

Con estas piezas en su lugar, tu aplicación gana escalabilidad y eficiencia. El storage gestiona los archivos, la base de datos gestiona los datos estructurados y el frontend une ambos leyendo la tabla y renderizando las imágenes con la URL guardada.

Este patrón es el recomendado por Supabase y es la base sobre la que vas a construir el feed, los perfiles y la subida de contenido en los siguientes pasos del proyecto. ¿Ya tienes definido cómo vas a nombrar tu columna de URL en la tabla? Cuéntalo en los comentarios.