Almacenamiento de objetos vs blobs en la base de datos: modela metadatos de archivos en Postgres, guarda bytes en almacenamiento de objetos y mantén descargas rápidas con costes predecibles.
Las subidas de usuarios suenan simples: aceptar un archivo, guardarlo, mostrarlo después. Eso funciona con pocos usuarios y archivos pequeños. Luego el volumen crece, los archivos son más grandes y el dolor aparece en sitios que no tienen nada que ver con el botón de subir.
Las descargas se vuelven lentas porque tu servidor de app o la base de datos están haciendo el trabajo pesado. Las copias de seguridad se vuelven enormes y lentas, así que las restauraciones tardan más justo cuando las necesitas. Las facturas de almacenamiento y ancho de banda (egreso) pueden dispararse porque los archivos se sirven de forma ineficiente, se duplican o nunca se limpian.
Lo que normalmente quieres es aburrido y fiable: transferencias rápidas bajo carga, reglas de acceso claras, operaciones sencillas (backup, restore, limpieza) y costes que se mantengan predecibles a medida que crece el uso.
Para llegar ahí, separa dos cosas que a menudo se mezclan:
Metadatos son la información pequeña sobre un archivo: quién lo posee, cómo se llama, tamaño, tipo, cuándo se subió y dónde vive. Esto pertenece a tu base de datos (como Postgres) porque necesitas consultarlo, filtrarlo y unirlo con usuarios, proyectos y permisos.
Bytes del archivo son el contenido real del archivo (la foto, el PDF, el vídeo). Almacenar bytes dentro de blobs de la base de datos puede funcionar, pero hace que la BD se vuelva más pesada, las copias de seguridad más grandes y el rendimiento más difícil de predecir. Poner los bytes en almacenamiento de objetos mantiene la base de datos enfocada en lo que hace mejor, mientras que los archivos se sirven de forma rápida y económica por sistemas diseñados para ello.
Cuando la gente dice «almacenar subidas en la base de datos», normalmente se refiere a blobs de la BD: ya sea una columna BYTEA (bytes en una fila) o los "large objects" de Postgres (una característica que guarda valores grandes por separado). Ambos pueden funcionar, pero ambos hacen que tu base de datos sea responsable de servir los bytes del archivo.
El almacenamiento de objetos es una idea diferente: el archivo vive en un bucket como un objeto, dirigido por una clave (por ejemplo uploads/2026/01/file.pdf). Está construido para archivos grandes, almacenamiento barato y descargas en streaming. También maneja muchas lecturas concurrentes bien, sin ocupar conexiones de la base de datos.
Postgres destaca en consultas, restricciones y transacciones. Es ideal para metadatos como quién posee el archivo, qué es, cuándo se subió y si puede descargarse. Esos metadatos son pequeños, fáciles de indexar y de mantener consistentes.
Una regla práctica:
Una comprobación rápida de sentido común: si backups, réplicas y migraciones se volverían dolorosos con los bytes incluidos, deja los bytes fuera de Postgres.
La configuración que la mayoría de equipos acaba usando es sencilla: guarda bytes en almacenamiento de objetos y guarda el registro del archivo (quién lo posee, qué es, dónde está) en Postgres. Tu API coordina y autoriza, pero no hace de proxy para subidas y descargas grandes.
Eso te da tres responsabilidades claras:
file_id estable, owner, tamaño, tipo de contenido y el puntero al objeto.Ese file_id estable se convierte en la clave primaria para todo: comentarios que referencian un adjunto, facturas que apuntan a un PDF, registros de auditoría y herramientas de soporte. Los usuarios pueden renombrar un archivo, puedes moverlo entre buckets y el file_id permanece igual.
Cuando sea posible, trata los objetos almacenados como inmutables. Si un usuario reemplaza un documento, crea un nuevo objeto (y normalmente una nueva fila o una fila de versión) en vez de sobrescribir bytes en el lugar. Simplifica el cacheo, evita la sorpresa de "el enlace antiguo devuelve un archivo nuevo" y te da una historia de rollback limpia.
Decide la privacidad desde el principio: privado por defecto, público solo por excepción. Una buena regla es: la base de datos es la fuente de verdad sobre quién puede acceder a un archivo; el almacenamiento de objetos aplica el permiso de corta duración que tu API conceda.
Con la separación limpia, Postgres guarda hechos sobre el archivo y el almacenamiento de objetos guarda los bytes. Eso mantiene tu base de datos más pequeña, backups más rápidos y consultas simples.
Una tabla uploads práctica solo necesita unos pocos campos para responder preguntas reales como «¿quién posee esto?», «¿dónde está almacenado?» y «¿es seguro descargarlo?»
CREATE TABLE uploads (
id uuid PRIMARY KEY,
owner_id uuid NOT NULL,
bucket text NOT NULL,
object_key text NOT NULL,
size_bytes bigint NOT NULL,
content_type text,
original_filename text,
checksum text,
state text NOT NULL CHECK (state IN ('pending','uploaded','failed','deleted')),
created_at timestamptz NOT NULL DEFAULT now()
);
CREATE INDEX uploads_owner_created_idx ON uploads (owner_id, created_at DESC);
CREATE INDEX uploads_checksum_idx ON uploads (checksum);
Algunas decisiones que ahorran problemas más adelante:
bucket + object_key como puntero de almacenamiento. Manténlo inmutable una vez subido.state. Cuando un usuario inicia una subida, inserta una fila pending. Cámbiala a uploaded solo después de que tu sistema confirme que el objeto existe y el tamaño (y preferiblemente el checksum) coinciden.original_filename solo para mostrar. No lo confíes para decisiones de tipo o seguridad.Si soportas reemplazos (como un usuario que vuelve a subir una factura), añade una tabla upload_versions separada con upload_id, version, object_key y created_at. Así puedes mantener historial, deshacer errores y evitar romper referencias antiguas.
Mantén las subidas rápidas haciendo que tu API gestione la coordinación, no los bytes. Tu base de datos sigue respondiendo, mientras el almacenamiento de objetos soporta el impacto de ancho de banda.
Empieza creando un registro de subida antes de enviar nada. Tu API devuelve un upload_id, dónde vivirá el archivo (un object_key) y un permiso de subida de corta duración.
Un flujo común:
pending, además del tamaño esperado y el tipo de contenido previsto.upload_id y cualquier campo de respuesta del almacenamiento (como ETag). Tu servidor verifica tamaño, checksum (si lo usas) y tipo de contenido, y entonces marca la fila como uploaded.failed y opcionalmente borra el objeto.Reintentos y duplicados son normales. Haz que la llamada de finalización sea idempotente: si el mismo upload_id se finaliza dos veces, devuelve éxito sin cambiar nada.
Para reducir duplicados por reintentos y re-subidas, guarda un checksum y trata «mismo owner + mismo checksum + mismo tamaño» como el mismo archivo.
Un buen flujo de descarga empieza con una URL estable en tu app, aunque los bytes vivan en otro sitio. Piensa: /files/{file_id}. Tu API usa file_id para buscar metadatos en Postgres, comprueba permisos y luego decide cómo entregar el archivo.
file_id.uploaded.Las redirecciones son simples y rápidas para archivos públicos o semi-públicos. Para archivos privados, las URL GET presignadas mantienen el almacenamiento privado pero permiten que el navegador descargue directamente.
Para vídeo y descargas grandes, asegúrate de que tu almacenamiento de objetos (y cualquier capa proxy) soporte peticiones por rangos (Range headers). Esto permite seek y descargas reanudables. Si enrutas los bytes a través de tu API, el soporte de rangos a menudo se rompe o se vuelve caro.
El cache es donde viene la velocidad. Tu endpoint estable /files/{file_id} suele ser no cacheable (es una puerta de autorización), mientras que la respuesta del almacenamiento puede cachearse según el contenido. Si los archivos son inmutables (nueva subida = nueva clave), puedes poner una vida de cache larga. Si sobrescribes archivos, mantén tiempos de cache cortos o usa claves versionadas.
Un CDN ayuda cuando tienes muchos usuarios globales o archivos grandes. Si tu audiencia es pequeña o mayormente en una región, el almacenamiento de objetos por sí solo suele ser suficiente y más barato para empezar.
Las facturas sorpresa suelen venir de descargas y churn, no de los bytes crudos en disco.
Presupuesta los cuatro motores que mueven la aguja: cuánto almacenas, con qué frecuencia lees y escribes (requests), cuántos datos salen del proveedor (egreso) y si usas un CDN para reducir descargas repetidas desde el origen. Un archivo pequeño descargado 10.000 veces puede costar más que un archivo grande que nadie toca.
Controles que mantienen el gasto estable:
Las reglas de ciclo de vida suelen ser la victoria más fácil. Por ejemplo: mantén fotos originales "hot" 30 días, luego muévelas a una clase más barata; guarda facturas 7 años, pero borra partes de subida fallidas después de 7 días. Incluso políticas básicas de retención detienen el crecimiento descontrolado del almacenamiento.
La deduplicación puede ser simple: guarda un hash de contenido (como SHA-256) en la tabla de metadatos y aplica unicidad por owner. Cuando un usuario sube el mismo PDF dos veces, puedes reutilizar el objeto existente y solo crear una nueva fila de metadatos.
Finalmente, rastrea el uso donde ya haces la contabilidad de usuarios: Postgres. Guarda bytes_uploaded, bytes_downloaded, object_count y last_activity_at por usuario o workspace. Así es fácil mostrar límites en la UI y disparar alertas antes de recibir la factura.
La seguridad para subidas se reduce a dos cosas: quién puede acceder a un archivo y qué puedes demostrar después si algo sale mal.
Empieza con un modelo de acceso claro y codifícalo en metadatos de Postgres, no en reglas puntuales dispersas.
Un modelo simple que cubre la mayoría de apps:
Para archivos privados, evita exponer claves crudas de objetos. Emite URLs de subida y descarga de corta duración con alcance limitado y rótalas con frecuencia.
Verifica cifrado en tránsito y en reposo. En tránsito significa HTTPS de extremo a extremo, incluidas subidas directas al almacenamiento. En reposo significa cifrado del lado del servidor en tu proveedor de almacenamiento y que backups y réplicas también estén cifrados.
Añade puntos de control para seguridad y calidad de datos: valida tipo y tamaño antes de emitir una URL de subida y luego valida de nuevo tras la subida (basado en los bytes realmente almacenados, no solo en el nombre del archivo). Si tu perfil de riesgo lo exige, ejecuta análisis de malware de forma asíncrona y pone el archivo en cuarentena hasta que pase.
Guarda campos de auditoría para poder investigar incidentes y cumplir lo básico: uploaded_by, ip, user_agent y last_accessed_at son una línea base práctica.
Si tienes requisitos de residencia de datos, elige la región de almacenamiento deliberadamente y mantenla consistente con donde corres el compute.
La mayoría de problemas con subidas no son por velocidad bruta. Vienen de decisiones de diseño que son convenientes al principio y luego dolorosas con tráfico real, datos reales y tickets de soporte reales.
Un ejemplo concreto: si un usuario reemplaza su foto de perfil tres veces, puedes acabar pagando por tres objetos antiguos para siempre a menos que programes limpieza. Un patrón seguro es un borrado suave en Postgres y luego un job en background que elimine el objeto y registre el resultado.
La mayoría de problemas aparecen cuando llega el primer archivo grande, un usuario refresca a mitad de subida o alguien borra una cuenta y los bytes quedan atrás.
Asegúrate de que tu tabla en Postgres registre el tamaño del archivo, checksum (para verificar integridad) y un camino de estados claro (por ejemplo: pending, uploaded, failed, deleted).
Una lista final:
uploaded con bytes faltantes.Una prueba concreta: sube un archivo de 2 GB, refresca la página al 30% y luego reanuda. Después descárgalo en una conexión lenta y busca en la mitad. Si alguno de los dos flujos falla, arréglalo ahora, no después del lanzamiento.
Una app SaaS simple suele tener dos tipos de subidas muy distintos: fotos de perfil (frecuentes, pequeñas, seguras para cachear) y facturas PDF (sensibles, deben permanecer privadas). Aquí es donde la separación entre metadatos en Postgres y bytes en almacenamiento de objetos rinde beneficios.
Así puede verse la metadata en una tabla files, con un par de campos que importan para el comportamiento:
| field | ejemplo foto de perfil | ejemplo PDF de factura |
|---|---|---|
kind | avatar | invoice_pdf |
visibility | private (servido vía signed URL) | private |
cache_control | public, max-age=31536000, immutable | no-store |
object_key | users/42/avatars/2026-01-17T120102Z.webp | orgs/7/invoices/INV-1049.pdf |
status | uploaded | uploaded |
size_bytes | 184233 | 982341 |
Cuando un usuario reemplaza una foto, trátalo como un archivo nuevo, no como una sobrescritura. Crea una nueva fila y un nuevo object_key, luego actualiza el perfil del usuario para apuntar al nuevo file ID. Marca la fila antigua como replaced_by=\u003cnew_id\u003e (o deleted_at) y borra el objeto antiguo después con un job en background. Esto mantiene historial, facilita rollbacks y evita condiciones de carrera.
Soporte y debugging se vuelven más sencillos porque los metadatos cuentan una historia. Cuando alguien dice "mi subida falló", soporte puede revisar status, un last_error legible, un storage_request_id o etag (para rastrear logs de almacenamiento), timestamps (¿se quedó estancada?) y owner_id y kind (¿es la política de acceso correcta?).
Empieza pequeño y haz que el camino feliz sea aburrido: los archivos se suben, los metadatos se guardan, las descargas son rápidas y nada se pierde.
Un buen primer hito es una tabla mínima en Postgres para metadatos de archivos más un flujo de subida directo y un flujo de descarga que puedas explicar en una pizarra. Cuando eso funcione de extremo a extremo, añade versiones, cuotas y reglas de ciclo de vida.
Elige una política de almacenamiento clara por tipo de archivo y escríbela. Por ejemplo, las fotos de perfil pueden ser cacheables y las facturas privadas accesibles solo por URLs de corta duración. Mezclar políticas dentro de un mismo prefijo de bucket sin plan es la manera en que ocurren exposiciones accidentales.
Añade instrumentación desde temprano. Los números que quieres desde el día uno son: tasa de fallo al finalizar subidas, tasa de huérfanos (objetos sin fila en BD y filas sin objeto), volumen de egreso por tipo de archivo, latencia P95 de descarga y tamaño medio de objeto.
Si quieres prototipar más rápido con este patrón, Koder.ai (koder.ai) está construido alrededor de generar apps completas desde chat y encaja con el stack común usado aquí (React, Go, Postgres). Puede ser una manera útil de iterar sobre el esquema, los endpoints y los jobs en background sin reescribir siempre el mismo andamiaje.
Después de eso, añade solo lo que puedas explicar en una frase: "guardamos versiones antiguas 30 días" o "cada workspace tiene 10 GB". Manténlo simple hasta que el uso real te obligue a cambiar.
Usa Postgres para los metadatos que necesitas consultar y proteger (owner, permisos, estado, checksum, puntero). Pon los bytes en almacenamiento de objetos para que las descargas y las transferencias grandes no consuman conexiones de base de datos ni inflen las copias de seguridad.
Hace que tu base de datos haga doble función como servidor de archivos. Aumenta el tamaño de las tablas, ralentiza backups y restauraciones, añade carga a la replicación y puede volver el rendimiento impredecible cuando muchos usuarios descargan a la vez.
Sí. Mantén un file_id estable en tu app, guarda metadatos en Postgres y guarda los bytes en almacenamiento de objetos referenciados por bucket y object_key. Tu API debe autorizar y emitir permisos de subida/descarga de corta duración en vez de proxyar los bytes.
Crea primero una fila pending, genera un object_key único y deja que el cliente suba directamente al almacenamiento usando un permiso de corta duración. Tras la subida, que el cliente llame a un endpoint de finalización para que el servidor verifique tamaño y checksum (si lo usas) antes de marcar la fila como uploaded.
Porque las subidas reales fallan y se reintentan. Un campo de estado permite distinguir archivos esperados pero ausentes (pending), completados (uploaded), rotos (failed) y eliminados (deleted) para que la interfaz, los jobs de limpieza y las herramientas de soporte se comporten correctamente.
Trata original_filename solo como dato para mostrar. Genera una clave de almacenamiento única (a menudo basada en UUID) para evitar colisiones, caracteres extraños y sorpresas de seguridad. Puedes seguir mostrando el nombre original en la UI mientras mantienes rutas de almacenamiento limpias y predecibles.
Usa una URL estable de la aplicación como /files/{file_id} como puerta de autorización. Tras comprobar acceso en Postgres, devuelve una redirección o un permiso de descarga firmado y de corta duración para que el cliente descargue directo desde el almacenamiento y tu API quede fuera del camino caliente.
Normalmente son las descargas y las descargas repetidas, no el almacenamiento en sí. Pon límites de tamaño y cuotas, usa reglas de retención/ciclo de vida, deduplica por checksum cuando tenga sentido y guarda contadores de uso para alertar antes de que la factura suba.
Almacena permisos y visibilidad en Postgres como fuente de verdad, y mantiene el almacenamiento privado por defecto. Valida tipo y tamaño antes y después de la subida, usa HTTPS de extremo a extremo, cifra en reposo y agrega campos de auditoría para investigar incidentes después.
Empieza con una tabla de metadatos, un flujo de subida directo al almacenamiento y un endpoint de descarga que haga de puerta. Luego añade jobs de limpieza para objetos huérfanos y filas borradas suavemente. Si quieres prototipar rápido en stack React/Go/Postgres, Koder.ai (koder.ai) puede generar endpoints, esquema y tareas en background desde chat y dejarte iterar sin reescribir el mismo boilerplate.