Block storage vs object storage: qué resuelve cada uno

1.00

Respuesta directa: block storage guarda el dato en bloques ligados a una máquina virtual, con latencia baja. Es el formato de bases de datos, volumen de sistema operativo y carga transaccional. Object storage guarda el dato como objetos con metadatos, accedidos por API, con escala casi ilimitada y costo por GB menor. Es el formato de archivo, medios, backup y log. NVMe es el tipo más rápido de block storage, indicado para bases exigentes y alta demanda de IOPS. Regla práctica: dato leído y escrito todo el tiempo pide block o NVMe; dato guardado y accedido de vez en cuando pide object.

La decisión block storage vs object storage parece un detalle de infraestructura, pero mueve costo, desempeño y la propia arquitectura de la aplicación. Y la elección correcta casi nunca es "el mejor almacenamiento". Es el almacenamiento que combina con el patrón de acceso de tu dato. Una base de datos quiere latencia baja y mucho IOPS. Un archivo quiere escala y costo por GB. Cuando separas esos dos mundos, dejas de pagar disco rápido para guardar logs y dejas de sufrir latencia corriendo una base en el lugar equivocado.

Este artículo es para quien está diseñando (o revisando) la capa de almacenamiento y necesita decidir qué va en cada tipo. Sin relleno: primero la diferencia en una frase, después cada tipo, cuándo usarlo, una tabla y una lista de 4 preguntas.

Block storage vs object storage: la diferencia en una frase

Piensa en block storage como un archivador de cajones numerados al lado de tu escritorio. El sistema operativo sabe en qué cajón está cada pedazo del archivo, toma los pedazos en orden y arma el dato al momento. Es rápido y previsible. La limitación es que el archivador está atado a ese escritorio: crece hasta cierto punto y sirve a una máquina a la vez.

Object storage es otro modelo. Imagina una bodega gigante donde cada caja tiene una etiqueta única con la descripción del contenido. No abres la caja para cambiar un ítem adentro. Pides la caja entera por la etiqueta, la recibes, y si quieres cambiar algo, devuelves una caja nueva en su lugar. La bodega tiene espacio casi infinito, sale barata por caja y accedes desde cualquier lugar con un pedido, que es la API. El intercambio es que buscar la caja toma un instante más que abrir el cajón de al lado.

La diferencia, entonces, no es calidad. Es patrón de acceso. El cajón de al lado para lo que tocas todo el tiempo. La bodega etiquetada para lo que guardas y accedes de vez en cuando.

Qué es block storage

Block storage divide el dato en bloques de tamaño fijo, cada uno con su propia dirección. Esos bloques se presentan a una máquina virtual como un volumen, un "disco". Quien organiza los bloques en archivos y carpetas es el sistema de archivos del propio SO, igual que lo haría con un HD o SSD local. Para la aplicación, es disco: lee y escribe sin saber que eso vive en una infraestructura de nube.

Este modelo entrega lo que bases de datos y sistemas transaccionales necesitan: latencia baja e IOPS alto (muchas operaciones de lectura y escritura por segundo). Por eso block storage es el lugar natural de:

Bases de datos relacionales como SQL Server, Oracle, MySQL, MariaDB y PostgreSQL.
El volumen de sistema operativo y el arranque de las máquinas.
ERP de mercado bajo carga, que escriben constantemente en una base.
Caché, colas y cualquier aplicación que trata el disco como memoria rápida.

En la práctica, es el disco donde corre tu instancia de base de datos gestionada. En Optidata, esos volúmenes usan almacenamiento premium, con NVMe como el tier más rápido (más sobre eso adelante).

Qué es object storage

Object storage no trata el dato como disco. Lo trata como objeto: el contenido, más los metadatos (quién lo creó, cuándo, tipo, etiquetas), más un identificador único. Esos objetos están en "cubetas" (buckets), en un espacio plano, sin la jerarquía de carpetas del sistema de archivos. Accedes a cada objeto por API, sobre HTTP, con operaciones simples de escribir y leer (PUT y GET), desde cualquier lugar.

La ganancia es escala y costo. Object storage crece en horizontal hacia los petabytes sin que provisiones volumen, y el costo por GB es bajo. Es el formato correcto para dato que guardas en volumen y no reescribes todo el tiempo:

Backup y archivado de datos.
Medios: imagen, video y audio.
Log, telemetría y dato para data lake.
Archivo estático de sitio y aplicación (assets, descargas, documentos).

Hay un detalle que cambia la cuenta cuando sirves muchos archivos: el tráfico de salida. En los hyperscalers, leer y distribuir esos objetos suele generar cobro de egress. En Optidata, el Object Storage no tiene cobro de tráfico, lo que deja previsible el costo de servir medios y distribuir archivos. Según Optidata, la plataforma procesa más de 15 petabytes, buena parte en cargas que combinan con este modelo.

Dónde entra el NVMe (y por qué no reemplaza a object storage)

NVMe no es una tercera categoría al lado de block y object. Es el tipo más rápido de block storage. Mientras los discos más antiguos conversan con el almacenamiento por interfaces como SATA y SAS, el NVMe habla con la memoria flash directo por PCIe, con muchas colas en paralelo. El resultado es latencia muy baja e IOPS muy alto.

Traducido a carga de trabajo: NVMe es el volumen que quieres debajo de una base de datos exigente, de un sistema transaccional con mucha concurrencia o de un ERP de mercado en el horario pico. Donde cada milisegundo de acceso a disco se vuelve tiempo de respuesta para el usuario, NVMe hace la diferencia.

Lo que NVMe no hace es resolver el problema que object storage resuelve. Es rápido y caro, ligado a una máquina, con escala limitada al volumen. Guardar millones de archivos fríos en NVMe es desperdicio. La lectura correcta es esta: NVMe para el dato caliente, object storage para el dato tibio y frío. Uno no pelea con el otro, cada uno cuida un patrón de acceso.

Cuándo usar block, object o NVMe

Usa block o NVMe cuando

Una base de datos va a escribir en ese volumen.
Es el disco de sistema operativo o el arranque de una máquina.
La aplicación es transaccional y sensible a la latencia (ERP de mercado, sistema de pedidos, finanzas).
Necesitas IOPS alto y respuesta inmediata. Si es base pesada bajo carga, prefiere NVMe.

No uses object storage cuando

Vayas a correr el disco de una base de datos. La semántica y la latencia están equivocadas para eso.
Sea el volumen de arranque de una máquina.
La aplicación necesite reescribir pedazos del dato todo el tiempo, y no reemplazar el archivo entero.

Usa object storage cuando

Necesitas guardar backup, medios, log o archivo en gran volumen.
El dato crece a decenas de terabytes o más y no puede costar caro por GB.
Quieres acceder y distribuir el contenido por API, desde cualquier lugar.

No fuerces block o NVMe cuando

El caso sea archivado en masa que rara vez se lee. Disco rápido aquí es dinero parado.
El objetivo sea servir archivo estático a escala. Object lo hace mejor y más barato.

Tabla comparativa: block storage vs object storage vs NVMe

Criterio	Block storage	Object storage	NVMe (tier premium de block)
Estructura del dato	Bloques de tamaño fijo, con dirección	Objetos con metadatos e ID único	Bloques, sobre flash en PCIe
Cómo se accede	Ligado a una VM, como un volumen	Por API/HTTP (PUT/GET), desde cualquier lugar	Ligado a una VM, como un volumen
Latencia	Baja	Mayor	Muy baja
IOPS y concurrencia	Alto	No es su fuerte	Muy alto
Escala	Limitada al volumen de la VM	Prácticamente ilimitada (petabytes)	Limitada al volumen de la VM
Costo por GB	Medio a alto	Bajo	Alto
Edición del dato	A nivel de bloque, continua	Reemplaza el objeto entero	A nivel de bloque, continua
Caso típico	Base, volumen de SO, ERP de mercado	Backup, medios, archivo, log, data lake	Base exigente, transaccional de alta demanda
Dónde tropieza	Guardar archivo en masa sale caro	No sirve para disco de base ni arranque	El costo no compensa para dato frío

Cómo elegir en 4 preguntas

Una guía rápida para decidir por carga de trabajo:

¿El dato se lee y escribe todo el tiempo, con prisa? Si sí, block o NVMe. Si se guarda y se accede de vez en cuando, object.
¿Una base de datos o el SO de la máquina van a usar ese volumen? Si sí, block o NVMe, sin discusión. Si es archivo, medios, backup o log, object.
¿El volumen va a crecer a decenas de terabytes o más de archivo? Si sí, object resuelve escala y costo. Si se queda en el disco de una VM, block alcanza.
¿Necesitas latencia mínima y mucho IOPS? Una base transaccional pesada o un ERP de mercado en el pico piden NVMe.

En la mayoría de los entornos, la respuesta no es elegir uno. Es combinar: base y sistema operativo en block o NVMe, backup y medios en object. El error común es tirar todo en el mismo tipo y pagar caro por eso, sea en factura, sea en latencia.

Ventajas y limitaciones de cada uno

Block storage

Lo que gana: latencia baja, IOPS alto y semántica de disco que cualquier SO y cualquier base entienden sin adaptación. Es previsible y simple de operar. Dónde limita: la escala queda atada al volumen de la máquina, el costo por GB es mayor y guardar archivo en masa aquí es desperdicio de un recurso caro.

Object storage

Lo que gana: escala casi sin techo, costo por GB bajo y acceso por API desde cualquier lugar. Es la mejor casa para backup, medios y distribución de archivo. Dónde limita: la latencia es mayor, no corre base ni volumen de arranque, y reemplazas el objeto entero en vez de editar un pedazo. Para dato caliente y transaccional, no sirve.

NVMe

Lo que gana: es el más rápido, con latencia mínima e IOPS altísimo. Hace una diferencia real debajo de una base exigente y un sistema de alta concurrencia. Dónde limita: costo alto y escala de volumen. No tiene sentido para dato frío y no resuelve guardar archivo en gran volumen, porque sigue siendo block.

Preguntas frecuentes

¿Block storage es más rápido que object storage?

Para acceder a dato caliente, sí. Block storage entrega latencia baja e IOPS alto porque el volumen está ligado a la máquina como un disco. Object storage se accede por API, sobre HTTP, y prioriza escala y costo, no velocidad de acceso. Por eso una base va en block (o NVMe) y el archivo va en object.

¿Puedo correr una base de datos en object storage?

No. Una base de datos necesita la semántica de disco y la latencia baja que solo block storage entrega. Object storage reemplaza el objeto entero en cada escritura y responde por API, lo que no combina con la escritura constante y granular de una base. Corre la base en block o NVMe y usa object para backup y exportación.

¿NVMe es lo mismo que SSD?

No exactamente. SSD es el tipo de medio (memoria flash). NVMe es el protocolo y la interfaz por la que esa flash conversa con la máquina, directo por PCIe. Un SSD común usa interfaces más antiguas como SATA. Un volumen NVMe usa flash sobre PCIe, con latencia menor e IOPS mayor. Todo NVMe usa flash, pero no todo SSD es NVMe.

¿Object storage es siempre más barato?

Por GB, generalmente sí, sobre todo para dato tibio y frío. Pero "más barato" depende del patrón de acceso. Para dato caliente, leído y escrito todo el tiempo, el costo real aparece en latencia y experiencia, no solo en el precio del GB. Y está el tráfico de salida: en una nube que cobra egress, servir muchos archivos encarece la cuenta. En Optidata no hay cobro de tráfico, lo que deja ese costo previsible.

¿Qué tipo debo usar para backup?

Object storage es la elección natural para backup, por la escala y el costo por GB. Suma a eso el backup offsite, que es mantener una copia de tus datos guardada fuera del sitio principal, por si pierdes el ambiente de origen. La combinación usual es backup en object y, sobre eso, una copia offsite.

¿Se puede usar block y object juntos?

Sí, y es lo más común. El diseño estándar coloca la base y el sistema operativo en block o NVMe y manda backup, medios y log a object. Pagas velocidad solo donde necesitas velocidad y pagas por escala barata donde necesitas guardar volumen. Así es como la capa de almacenamiento queda equilibrada en costo y desempeño.

¿Necesitas diseñar esta capa por carga de trabajo? Optidata lo prueba contigo en una POC sin compromiso, con precio fijo y licencias de base de datos incluidas.