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
| Criterio | Object storage | Block storage | File storage |
|---|---|---|---|
| Unidad | Objeto (clave + datos + metadatos) | Bloque de tamaño fijo | Fichero en árbol de directorios |
| Acceso | API S3 sobre HTTP | Disco montado (iSCSI, NVMe-oF) | NFS, SMB/CIFS |
| Latencia | Decenas de ms (red) | Muy baja (µs a pocos ms) | Baja a media |
| Escalabilidad | De GB a PB, casi ilimitada | Acotada por volumen | Limitada por la jerarquía |
| Metadatos | Ricos y personalizables | Mínimos | POSIX/ACL, timestamps |
| Escrituras aleatorias | No (objeto completo) | Sí, su punto fuerte | Sí |
| Caso típico | Backups, medios, datasets, logs | Bases de datos, discos de VM | Recursos compartidos, home dirs |
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.jpges 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
¿Puedo usar object storage como disco de mi servidor? +
¿Es el object storage más lento que el block storage? +
¿Qué diferencia hay entre file storage y object storage? +
Tu capa de objetos, compatible con S3
Escala de GB a PB sin cambiar tus herramientas.
Hazte Founding Otter