Object Storage vs Block Storage

Object storage, block storage y file storage no compiten por el mismo trabajo: cada uno resuelve un problema distinto. Si eliges la capa equivocada acabas pagando de más, peleando con la escala o sufriendo latencia donde no toca. Esta guía explica en profundidad cómo funciona cada modelo, cómo se accede a los datos, qué metadatos y garantías ofrece, y cuándo conviene cada uno con ejemplos concretos.

Las tres formas de guardar datos

Toda infraestructura termina apoyándose en uno de estos tres paradigmas de almacenamiento, o en una combinación de los tres. La diferencia no es solo "dónde" se guardan los bytes, sino la unidad con la que trabajas y cómo accedes a ella: bloques de disco, ficheros en un árbol de directorios u objetos identificados por una clave. Entender esa unidad es lo que evita la mayoría de errores de arquitectura.

Block storage

El block storage expone volúmenes en bruto que el sistema operativo ve como discos. Tú los formateas (ext4, XFS, NTFS), los montas y, a partir de ahí, el almacenamiento es transparente: una base de datos o un sistema de archivos escribe y lee bloques de tamaño fijo en posiciones arbitrarias del volumen. El dispositivo no sabe qué hay dentro de cada bloque; solo direcciona sectores.

Esa cercanía al hardware es su gran ventaja. Las escrituras y lecturas aleatorias son rápidas, la latencia es de microsegundos a pocos milisegundos y puedes garantizar IOPS sostenidos. A cambio, un volumen suele estar atado a una máquina y a una zona de disponibilidad concreta: escalar significa agrandar el disco o migrarlo, no añadir capacidad infinita de forma elástica.

• Unidad de acceso: el bloque, direccionado por offset dentro del volumen.
• Protocolos típicos: iSCSI, NVMe-oF, Fibre Channel o discos virtuales de la VM.
• Metadatos: prácticamente ninguno a nivel de bloque; el sentido lo pone el sistema de archivos que montas encima.
• Punto fuerte: latencia baja y escrituras aleatorias para cargas transaccionales.
• Limitación: capacidad por volumen acotada y acoplamiento a una máquina/zona.

File storage

El file storage añade una capa de organización: ficheros dentro de una jerarquía de carpetas, compartida por red mediante protocolos como NFS o SMB/CIFS. Varios clientes pueden montar el mismo recurso y trabajar sobre rutas familiares (/datos/proyecto/informe.pdf), con permisos POSIX o ACL y bloqueos de fichero para coordinar accesos concurrentes.

Es el modelo más intuitivo para humanos y para aplicaciones heredadas que esperan un sistema de archivos compartido: directorios home, recursos de equipo, software legacy que escribe en rutas. El precio que se paga es de escala: la jerarquía y los metadatos POSIX se vuelven un cuello de botella cuando hablas de cientos de millones de ficheros, y la disponibilidad depende del servidor o cabina que sirve el recurso.

• Unidad de acceso: el fichero, localizado por su ruta dentro de un árbol de directorios.
• Protocolos típicos: NFS, SMB/CIFS.
• Metadatos: permisos POSIX/ACL, timestamps, propietario; ricos para gestión, pero rígidos.
• Punto fuerte: acceso compartido y semántica de sistema de archivos conocida.
• Limitación: la jerarquía limita el rendimiento a escalas muy grandes.

Object storage

El object storage rompe con la jerarquía. Cada dato es un objeto: el contenido binario más un conjunto de metadatos, identificado por una clave única dentro de un bucket. No hay carpetas reales (lo que parecen "directorios" son simplemente prefijos en la clave) ni montas nada: accedes por HTTP mediante la API S3, con operaciones como PUT, GET, LIST y DELETE.

Ese diseño plano es lo que permite escalar de forma casi ilimitada, de gigabytes a petabytes, repartiendo objetos por muchos nodos sin un índice jerárquico que se sature. La durabilidad se consigue con Erasure Coding: cada objeto se trocea y se codifica en fragmentos redundantes repartidos, de modo que se reconstruye aunque fallen varios discos. La contrapartida es la latencia: una petición HTTP a través de la red está en el rango de decenas de milisegundos, perfecta para leer un fichero entero pero inadecuada para las miles de escrituras aleatorias por segundo que pide una base de datos.

En OtterStorage los objetos viven detrás del endpoint https://s3.otterstorage.io y puedes elegir región: EU-MAD (Madrid), EU-FRA (Frankfurt) o US-EAST. Una operación tan simple como subir un objeto se ve así con la AWS CLI:

aws --endpoint-url https://s3.otterstorage.io \
  s3 cp ./dataset-2026.parquet s3://datos-analitica/raw/dataset-2026.parquet

# Listar lo que hay bajo un prefijo (los "directorios" son solo claves)
aws --endpoint-url https://s3.otterstorage.io \
  s3 ls s3://datos-analitica/raw/

• Unidad de acceso: el objeto, localizado por su clave dentro de un bucket.
• Protocolo: API S3 sobre HTTP/HTTPS, accesible desde cualquier sitio.
• Metadatos: ricos y extensibles (Content-Type, ETag y pares clave-valor propios por objeto).
• Punto fuerte: escala masiva, durabilidad alta y direccionamiento global.
• Limitación: no apto para escrituras aleatorias de baja latencia ni para montar como disco.

Metadatos: el rasgo que más diferencia a object

Donde block apenas guarda metadatos y file se ciñe a los atributos POSIX, el object storage trata los metadatos como ciudadanos de primera clase. Cada objeto puede llevar etiquetas propias que luego usas para clasificar, aplicar reglas de ciclo de vida o filtrar. Eso convierte al bucket en algo más parecido a un catálogo de datos que a un disco:

aws --endpoint-url https://s3.otterstorage.io \
  s3api put-object \
  --bucket datos-analitica \
  --key informes/2026/q2.csv \
  --body q2.csv \
  --content-type text/csv \
  --metadata proyecto=ventas,confidencialidad=interno,retencion=7y

Tabla comparativa: object vs block vs file

Cuándo elegir cada uno

La pregunta correcta no es "cuál es mejor", sino "qué unidad de acceso pide mi carga". Una regla rápida que casi nunca falla:

• Base de datos en producción (PostgreSQL, MySQL, MongoDB) → block storage. Necesita escrituras aleatorias de baja latencia y un sistema de archivos montado.
• Backups de esa base de datos → object storage, idealmente con inmutabilidad. Lee y escribe ficheros completos y necesita escala y durabilidad, no IOPS.
• Imágenes, vídeos y adjuntos de tu app → object storage, servidos por la API S3.
• Disco de arranque de una VM → block storage.
• Datasets de IA, data lakes, logs y artefactos de CI → object storage; son datos no estructurados que crecen sin parar.
• Recurso compartido por varios equipos con rutas y permisos POSIX → file storage.

Si tu carga necesita modificar trozos pequeños de un archivo enorme muchas veces por segundo, es block. Si trabaja con archivos completos que se escriben una vez y se leen muchas, y quieres olvidarte de la capacidad, es object. Si necesitas que varias máquinas vean el mismo árbol de carpetas con semántica de sistema de archivos, es file.

El patrón habitual: se complementan

En la práctica casi ninguna arquitectura elige solo una capa. Lo normal es combinar block para lo caliente y object para lo masivo: la base de datos vive en un volumen de bloque rápido y sus copias viajan a S3 con retención inmutable. Con backups de PostgreSQL a S3 tienes el ejemplo canónico: producción en block, histórico en object.

Sobre OtterStorage ese flujo se apoya en piezas concretas. Las copias inmutables se protegen con Object Lock (WORM) en modos Governance o Compliance, evitando que un ransomware o un borrado accidental se lleve tus backups. Las reglas de lifecycle mueven o caducan objetos según su antigüedad, y el versionado conserva versiones previas de cada objeto. Y, como no cobramos por peticiones ni por borrados, listar o rotar millones de objetos no dispara la factura.

{
  "Rules": [
    {
      "ID": "expira-backups-antiguos",
      "Status": "Enabled",
      "Filter": { "Prefix": "backups/postgres/" },
      "Expiration": { "Days": 90 }
    }
  ]
}

Mitos frecuentes

Alrededor de estas tecnologías circulan ideas que llevan a malas decisiones. Estas son las que más vemos:

• "El object storage es solo un disco de red más lento." No es un disco: es un servicio HTTP con una semántica distinta. No lo montas ni haces seek dentro de un objeto; trabajas con objetos completos identificados por clave.
• "Puedo poner mi base de datos sobre S3." Una base de datos transaccional necesita escrituras aleatorias de baja latencia que el object storage no ofrece. Lo correcto es la base en block y sus copias en object.
• "El object storage es más barato siempre." Depende del patrón de acceso. Para datos no estructurados y de gran volumen suele salir mejor, sobre todo si el proveedor no cobra por peticiones; para IOPS calientes, block es lo idóneo. La elección por coste se entiende mejor con nuestra guía de cómo reducir costes de almacenamiento cloud.
• "Los buckets tienen carpetas." No las hay de verdad. La jerarquía es una convención sobre la clave: fotos/2026/playa.jpg es una sola clave con barras, no carpetas anidadas.
• "Object significa que pierdo control sobre la consistencia y la seguridad." Al contrario: dispones de versionado, Legal Hold por bucket y access keys aisladas por bucket para acotar el blast radius de cada credencial.

En resumen

Block para lo que necesita latencia y montaje; file para compartir un árbol de ficheros; object para escalar y durar. La mayoría de arquitecturas modernas usan los tres a la vez, cada uno donde brilla. Si tu caso es backups, medios, datasets o logs, el object storage es la respuesta, y migrar a él no obliga a cambiar tus herramientas: la API S3 es un estándar que ya hablan AWS CLI, rclone, Restic, Velero o Terraform. Cuando quieras dar el salto, la documentación tiene las guías para arrancar en minutos.

Preguntas frecuentes