Almacenamiento de objetos vs blobs en la base de datos para subidas rápidas y baratas

El verdadero problema con las subidas de usuarios

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.

Almacenamiento de objetos vs blobs en la base de datos, en términos sencillos

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:

• Usa Postgres para metadatos de archivos, permisos y relaciones.
• Usa almacenamiento de objetos para los bytes cuando los archivos puedan superar unos pocos MB, o cuando las descargas sean frecuentes.
• Considera los blobs de BD solo para activos diminutos que deban estar transaccionalmente ligados a un registro (como un icono pequeño) y estás seguro de que el crecimiento de la BD se mantendrá modesto.

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.

Una arquitectura simple que se mantiene manejable

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:

• Postgres mantiene una fila pequeña por archivo: un file_id estable, owner, tamaño, tipo de contenido y el puntero al objeto.
• Almacenamiento de objetos guarda los bytes reales, optimizado para archivos grandes y almacenamiento barato.
• Tu API crea y autoriza registros de archivo, y entrega permisos de corta duración al almacenamiento.

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.

Cómo modelar metadatos de archivos en Postgres

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:

• Usa bucket + object_key como puntero de almacenamiento. Manténlo inmutable una vez subido.
• Rastrea el 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.
• Guarda 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.

Flujo de subida paso a paso (sin bloquear tu API)

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:

1. El cliente pide subir: tu API crea una fila con pending, además del tamaño esperado y el tipo de contenido previsto.
2. La API devuelve una URL presignada: para archivos grandes, genera una URL de subida presignada. Para archivos pequeños (como avatares), aún puedes hacer proxy a través del backend si quieres código cliente más simple.
3. El cliente sube directamente al almacenamiento: el navegador o la app móvil envían los bytes al almacenamiento, no a tu API.
4. Finalizar: el cliente llama a tu API con 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.
5. Fallar de forma segura: si la verificación falla, marca 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.

Flujo de descarga paso a paso (rápido y amigable con cache)

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.

1. El cliente solicita tu URL estable con file_id.
2. La API verifica que el usuario puede acceder y que el archivo está uploaded.
3. La API devuelve o bien una redirección al almacenamiento (a menudo lo mejor), o una URL GET presignada de corta duración para archivos privados.
4. El cliente descarga directamente desde el almacenamiento, manteniendo tu API y servidores fuera del camino caliente.

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.

Mantener costes predecibles con el tiempo

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:

• Limita el tamaño por subida y establece cuotas por usuario según el plan.
• Limita la tasa de subidas y descargas para evitar abuso y bucles accidentales.
• Usa reglas de ciclo de vida para mover archivos antiguos a una clase más barata o borrarlos cuando ya no sean necesarios.
• Deduplica por checksum para que reintentos o re-subidas no creen copias extra.
• Guarda contadores de uso en Postgres para que la facturación y alertas se basen en datos reales, no en estimaciones.

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.

Fundamentos de seguridad y cumplimiento para subidas

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.

Control de acceso que refleje el uso real

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:

• Solo propietario: solo el uploader (y admins) pueden acceder.
• Compartido: accesible a usuarios específicos o a un equipo/workspace.
• Público: accesible sin login (usar con moderación y aún así rastrearlo).

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.

Controles de cumplimiento que te salvan después

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.

Errores comunes que causan ralentizaciones e incidentes

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.

• Guardar bytes dentro de Postgres: Funciona para apps pequeñas, luego los backups se disparan, las restauraciones tardan y el mantenimiento rutinario se vuelve arriesgado. Una sola tabla grande puede ralentizar vacuum, replicación e incluso consultas simples.
• Usar el nombre de archivo proporcionado por el usuario como clave del objeto: Ocurren colisiones (dos usuarios suben "invoice.pdf") y caracteres extraños crean casos límite. Mantén los nombres como datos de presentación y genera una clave única (por ejemplo un UUID) para el almacenamiento.
• Saltar validación en la finalización: Aunque valides en el cliente, necesitas comprobaciones del lado del servidor para tamaño, tipo de contenido y propiedad cuando marcas una subida como completa.
• Hacer objetos públicos por accidente y nunca rotar accesos: Una política de bucket "temporalmente" pública o URLs de larga duración suelen volverse permanentes. Prefiere enlaces de descarga de corta duración y ten una forma de revocar acceso rápido.
• Borrar solo un lado (metadatos o bytes): Borrar la fila de Postgres pero dejar el objeto genera fugas silenciosas de coste. Borrar el objeto pero mantener metadatos crea descargas rotas y carga de soporte.

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.

Lista de verificación rápida antes del lanzamiento

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:

• Confirma que los reintentos son seguros: intentos repetidos no deben crear objetos extra ni filas uploaded con bytes faltantes.
• Haz las subidas reanudables o al menos reiniciables sin tickets de soporte (los timeouts y redes móviles ocurrirán).
• Verifica que las descargas manejen peticiones por rangos para que archivos grandes empiecen rápido y se reanuden tras una pausa.
• Define la eliminación de extremo a extremo: marca metadata como tombstone, borra los bytes del objeto y maneja la limpieza retrasada si un job falla.
• Añade monitorización básica: tasa de error de subida/descarga, crecimiento de almacenamiento y picos repentinos de egreso.

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.

Escenario de ejemplo: fotos y facturas en una misma app

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:

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?).

Próximos pasos para implementar sin sobreconstruir

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.