NVMe vs SSD SATA en VPS: ¿realmente importa?

¿Importa NVMe en un VPS?

NVMe importa en un VPS cuando el software realiza muchas lecturas y escrituras pequeñas y espera a que cada una termine. Cambia muy poco el rendimiento de un sitio que sirve páginas almacenadas en caché o de un programa que pasa la mayor parte del tiempo esperando a la red. El tipo de almacenamiento es un factor. El hipervisor que se encuentra delante del disco y los demás guests que comparten el mismo host determinan el límite de rendimiento que realmente obtiene.

Qué cambia NVMe y qué no

NVMe (non-volatile memory express) no es un tipo de memoria flash. Es el protocolo y la conexión que se usan para acceder a la memoria flash. Un dispositivo NVMe usa líneas PCIe (peripheral component interconnect express) y se comunica mediante NVMe. Una SSD SATA (serial ATA) usa un enlace SATA y se comunica mediante AHCI (advanced host controller interface). Los chips de memoria que almacenan los datos pueden ser idénticos en ambos casos.

Hay dos diferencias, y ambas están relacionadas con la ruta de comandos, no con el almacenamiento en sí.

Colas. AHCI proporciona al kernel una cola de comandos con capacidad para 32 comandos. NVMe permite miles de colas, en la práctica una por núcleo de CPU, y cada una puede ser mucho más profunda que 32. Un proceso que lee un bloque cada vez no puede apreciar esa diferencia. Una base de datos con 64 lecturas pendientes sí: en SATA, la solicitud número 33 espera un espacio en la cola antes de que el dispositivo la reciba, mientras que el dispositivo NVMe acepta todas y trabaja con ellas al mismo tiempo.

Ancho del enlace. Un enlace SATA III funciona a 6 Gbit/s, lo que equivale aproximadamente a 550 MB/s de datos reales después de la sobrecarga del protocolo. Es un límite fijo, independientemente de la memoria flash que haya detrás. Cuatro líneas PCIe transportan varios gigabytes por segundo, por lo que el enlace deja de ser el factor limitante.

La latencia suele generar expectativas incorrectas. Con una profundidad de cola de 1, es decir, una sola solicitud en curso, una SSD SATA responde a una lectura de 4k en unos 100 a 150 microsegundos. NVMe responde en unos 80 a 100. Ambas son rápidas y ningún sistema que ejecute notará la diferencia en una sola solicitud. La diferencia aparece con la concurrencia. La profundidad de cola, es decir, el número de solicitudes en curso al mismo tiempo, determina si los dos medios se comportan de forma parecida o muy diferente.

El almacenamiento de bloques en red es una tercera clase, con características físicas distintas. Una escritura atraviesa la red hasta un clúster de almacenamiento y sólo recibe confirmación cuando el clúster la ha almacenado, por lo que su latencia se mide en milisegundos en lugar de microsegundos. A cambio de esa latencia se obtiene durabilidad: el volumen sobrevive al host al que está conectado y se puede crear una instantánea y cambiar su tamaño.

Cifras publicadas habituales: NVMe, SATA SSD y almacenamiento de red

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

Un dispositivo NVMe local suele anunciar 184,000 IOPS de lectura aleatoria 4k (operaciones de entrada/salida por segundo) con una profundidad de cola de 32. La misma prueba en un SATA SSD suele situarse cerca de 90,000, limitada por la única cola AHCI y el enlace de 6 Gbit/s. El almacenamiento de bloques en red suele estar limitado por el proveedor y no por el hardware, y 12,500 es un límite superior documentado habitual.

La latencia expresa lo mismo en la unidad que perciben los usuarios. La latencia de lectura p99, es decir, la del 1 por ciento más lento de las solicitudes, es de aproximadamente 0.4 ms en NVMe local y 1.2 ms en SATA. Si la red forma parte de la ruta, aumenta a 6.5 ms, más de diez veces la cifra de NVMe.

Las lecturas secuenciales muestran la mayor diferencia, pero son la medida menos útil: 3,400 MB/s frente a 550 MB/s. Casi ningún proceso de un servidor lee un archivo grande completo a máxima velocidad. Las columnas de acceso aleatorio y latencia describen mejor lo que realmente hacen una base de datos, una cola de correo o un gestor de paquetes.

Qué cargas de trabajo notan el disco

Una regla explica todos los casos: una carga de trabajo sólo nota el disco cuando espera al disco. Linux mantiene en la RAM los datos de archivos usados recientemente, en la caché de páginas, por lo que la segunda lectura de un archivo nunca llega al almacenamiento. Si el conjunto de trabajo, es decir, los datos que se usan realmente, cabe en la RAM, las lecturas se convierten en lecturas de memoria después de la primera pasada. Las escrituras son diferentes. Cualquier escritura que la aplicación vacíe con fsync() debe estar en almacenamiento estable antes de que la aplicación pueda continuar.

Trabajo que confirma cambios. PostgreSQL, MySQL y SQLite llaman a fsync() o fdatasync() al confirmar cambios, y cada confirmación espera a que el dispositivo responda. Por tanto, la tasa de confirmaciones de una conexión está determinada por la latencia de escritura, no por el ancho de banda. Un dispositivo que vacía los datos en 0.2 ms permite muchas más confirmaciones por segundo que uno que tarda 5 ms, y ningún nivel de rendimiento cambia ese hecho. MySQL lo indica en el registro de errores cuando el vaciado no puede mantener el ritmo:

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL lo informa en sus líneas de checkpoint, donde un valor alto de sync= significa que el vaciado fue lento:

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

Trabajo que accede a muchos archivos pequeños. Cada archivo implica operaciones de metadatos que una lectura secuencial grande no necesita. npm install, git clone de un repositorio grande, desempaquetar imágenes de contenedor, un almacén de correo Maildir y una copia de seguridad que recorre un árbol grande dedican la mayor parte del tiempo al acceso aleatorio pequeño. un trabajo de copia de seguridad de restic en un VPS lee y calcula el hash de cada archivo que no ha visto antes, por lo que el tiempo transcurrido de una copia de seguridad de un millón de archivos sigue de cerca la latencia de lectura aleatoria. Lo mismo ocurre con du -sh, que sólo lee metadatos.

Las bases de datos que superan la capacidad de la RAM también pertenecen a esta categoría. Cuando el índice deja de caber en la caché de páginas, cada consulta se convierte en una lectura aleatoria y el disco vuelve a formar parte de la ruta crítica.

Qué cargas de trabajo no notan el disco

Un blog o un sitio pequeño de una empresa. Las páginas son pequeñas, la caché de páginas las conserva todas después de la primera solicitud y el límite lo marcan la CPU al renderizarlas o el ancho de banda para los recursos. Un stack LAMP en Ubuntu 24.04 que sirve un sitio con poco tráfico apenas realiza operaciones de E/S de disco cuando la caché ya está caliente.

Streaming multimedia. Un flujo 4K a 40 Mbit/s lee 5 MB/s. Diez flujos leen 50 MB/s, una carga que incluso el almacenamiento de bloques en red puede servir sin problemas. Un servidor multimedia Jellyfin en un VPS está limitado por la cuota de salida de red y por la CPU cuando transcodifica, no por el medio de almacenamiento.

Inferencia local de modelos. Ejecutar Ollama en un VPS para alojar un LLM propio lee el archivo del modelo una vez y después trabaja en la RAM. NVMe reduce de minutos a segundos el tiempo de carga de un modelo de 20 GB. No cambia los tokens por segundo, que están limitados por el ancho de banda de memoria y la CPU.

Cualquier proceso que espere a un servicio externo. Un worker que dedica 800 ms por trabajo a una solicitud HTTP no funcionará más rápido con un disco mejor.

Por qué el hipervisor importa tanto como el medio

Nunca se comunica directamente con el dispositivo. Se comunica con un disco virtual que el hipervisor presenta, normalmente mediante virtio, y varias decisiones de esa capa importan más que elegir NVMe o SATA.

No puede ver el medio desde el sistema invitado. lsblk -d -o NAME,ROTA,SIZE,MODEL muestra vda con el modelo vacío, porque virtio no transmite la identidad de la unidad. cat /sys/block/vda/queue/rotational informa de lo que anuncia el hipervisor, por lo que un valor de 0 no demuestra que el almacenamiento sea flash. nvme list, del paquete nvme-cli, no muestra nada en la mayoría de los VPS, aunque el host tenga unidades NVMe, porque su disco es un dispositivo virtio y no un dispositivo NVMe. Cuando un plan indica NVMe, normalmente describe el almacenamiento del host. Su volumen puede seguir estando conectado a través de la red.

El modo de caché del host modifica más los resultados que el medio. Con la caché de escritura writeback activada en el host, un `fsync() del sistema invitado puede devolver el resultado en cuanto el host tiene los datos en su propia RAM. Esto produce un resultado de referencia que ningún dispositivo físico podría alcanzar. También significa que un fallo del host puede perder escrituras que la base de datos considera seguras. Con el modo de caché none`, los resultados son menores y representan mejor el rendimiento real.

Límites y créditos de ráfaga. Muchos proveedores limitan las IOPS por volumen o por plan, y muchos volúmenes de red utilizan una asignación de ráfaga. Una asignación de ráfaga es una reserva de créditos: el volumen funciona a alta velocidad mientras quedan créditos y después baja a una línea base mucho menor. El síntoma es fácil de reconocer. Una importación o restauración se ejecuta rápidamente durante varios minutos, después se ralentiza de forma considerable y permanece lenta, sin que haya cambiado nada en su configuración. Ha consumido los créditos.

Vecinos. En un host compartido, la latencia del disco cambia según lo que hagan los demás sistemas invitados. Por eso debe medir más de una vez. Ejecute la misma prueba por la mañana y de nuevo por la tarde, y compare la variación. En un host con mucha carga, la diferencia entre dos ejecuciones en el mismo volumen suele ser mayor que la diferencia publicada entre dos medios.

Cómo medir el almacenamiento que realmente tiene su VPS

Instale fio, el benchmark estándar de E/S, y realice una medición. Antes, tenga en cuenta tres precauciones. La prueba crea un archivo, por lo que utiliza espacio de disco y cuenta para cualquier límite de IOPS que se le facture. Mantenga las ejecuciones cortas. No la ejecute con una profundidad de cola máxima en un volumen que atiende tráfico activo, porque competirá con su propia aplicación.

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

Lectura aleatoria con una profundidad de cola de 32, que es la profundidad que indican los proveedores:

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

La línea importante comienza con read:

  read: IOPS=184k, BW=719MiB/s (754MB/s)(21.1GiB/30001msec)

--direct=1 omite la caché de páginas del sistema invitado, por lo que el resultado describe el dispositivo y no la RAM. Si lo omite, medirá la memoria, que devuelve un valor que ningún disco puede alcanzar. Use --size=4G o un valor superior si tiene espacio, porque un archivo de 1G puede caber por completo en la caché del host y hacer que el resultado parezca mejor.

La profundidad de cola 1 muestra la latencia real, que es la que experimenta un proceso de un solo subproceso:

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

La prueba de commits permite prever el comportamiento de una base de datos. Escribe 4k y llama a fdatasync() después de cada escritura, por lo que la tasa indicada incluye el vaciado:

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

La cifra de IOPS de esa ejecución se aproxima al número máximo de transacciones pequeñas por segundo que una conexión de base de datos puede confirmar, porque un commit espera al mismo vaciado.

Para obtener una muestra rápida sin fio:

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

El valor mdev, la desviación media, es tan importante como el promedio. Una desviación alta en un servidor inactivo indica que el backend de almacenamiento es compartido y está ocupado.

Cómo leer el resultado

En julio de 2026, estas son lecturas razonables para un VPS pequeño. Decenas de miles de IOPS de lectura aleatoria de 4k con una profundidad de cola de 32, junto con una latencia inferior a unos 0.3 ms con profundidad de cola 1, son valores compatibles con almacenamiento flash local. Una latencia de varios milisegundos con profundidad de cola 1 indica una ruta de red, independientemente del nombre del plan. Las lecturas secuenciales que se detienen cerca de 550 MB/s son características de un enlace SATA. Un valor muy superior a lo que puede alcanzar cualquier dispositivo individual indica que hay almacenamiento en caché en la ruta, casi siempre en el host.

Para ver cómo la carga de trabajo activa está utilizando el disco:

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

En la salida de iostat -x, lea r_await y w_await, que indican los milisegundos medios que esperó una solicitud, y aqu-sz, que indica la longitud media de la cola. Ignore %util en un disco virtual. Este valor indica el porcentaje de tiempo durante el que hubo al menos una solicitud pendiente. No informa de la saturación en un dispositivo que atiende muchas solicitudes simultáneamente. Por eso, un %util de 100 junto con un r_await de 0.2 ms indica un disco ocupado pero en buen estado. En vmstat, la columna wa indica el porcentaje de tiempo de CPU dedicado a esperar operaciones de E/S. Si /proc/pressure/io existe en su kernel, su valor some avg10= indica la proporción de los últimos 10 segundos durante la que al menos una tarea estuvo bloqueada esperando E/S. Este es el indicador más directo para determinar si el almacenamiento es el cuello de botella.

Cómo se ve una VPS limitada por el disco

Una carga media alta, con la CPU inactiva y un valor elevado de wa en vmstat, indica que los procesos están en cola a la espera del disco. La señal más clara del kernel es este mensaje en dmesg -T:

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

La línea aparece porque un hilo del kernel esperó más de dos minutos a que el almacenamiento respondiera, por lo que el watchdog de tareas bloqueadas registró el evento. jbd2 es el hilo del journal de ext4, lo que indica que todo el sistema de archivos estaba esperando, no que hubiera un único programa con un comportamiento incorrecto. En una VPS, normalmente apunta al backend de almacenamiento o a un límite de IOPS agotado.

Los síntomas de la aplicación siguen el mismo patrón. El tiempo de respuesta mediano se mantiene en niveles aceptables, mientras que las solicitudes más lentas forman una cola larga, porque sólo las solicitudes que acceden al disco sufren la demora. apt upgrade permanece en Unpacking durante minutos, porque dpkg vacía los datos pendientes mientras escribe. git status tarda varios segundos en un repositorio grande. Estos costes corresponden a metadatos y operaciones de vaciado, por lo que un mayor ancho de banda no resolvería el problema.

Qué hacer cuando el disco es el límite

Compre RAM antes que IOPS. Si el conjunto de trabajo cabe en la caché de páginas, las lecturas dejan de llegar al disco. Duplicar la memoria suele ofrecer más rendimiento que cambiar a una clase de almacenamiento más rápida y normalmente cuesta menos.

Reduzca el número de vaciados cuando los datos lo permitan. En PostgreSQL, synchronous_commit = off permite que una confirmación se devuelva antes de que la escritura llegue al disco. Si el servidor falla, puede perder la última fracción de segundo de transacciones. La base de datos no se corrompe porque el write-ahead log se sigue escribiendo en orden. Esta compensación es adecuada para una copia de análisis y no lo es para pagos. innodb_flush_log_at_trx_commit = 2 en MySQL aplica la misma compensación.

Agrupe los archivos pequeños. Una transferencia o copia de seguridad de un millón de archivos pequeños está dominada por el coste individual de cada archivo. Por eso, en almacenamiento con alta latencia, es más rápido archivarlos primero y mover un único flujo que copiar el árbol archivo por archivo.

Mantenga activo discard en los volúmenes thin. En el almacenamiento con aprovisionamiento thin, el backend no sabe que un bloque está libre hasta que el sistema de archivos se lo indica. Un volumen que nunca ejecuta trim pierde rendimiento de escritura de forma gradual. Ubuntu incluye un temporizador semanal para esto:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av muestra los bytes liberados mediante trim para cada punto de montaje. Un mensaje que indique que la operación discard no es compatible significa que el disco virtual no transmite discard al host. No hay nada que deba corregir.

No ajuste el planificador de E/S. En un disco virtio, cat /sys/block/vda/queue/scheduler suele mostrar none, y la planificación real se realiza en el host, al que no tiene acceso. Omita también noatime: Ubuntu monta con relatime de forma predeterminada, lo que ya evita casi todas las escrituras de atime.

Elegir un plan

Pague por NVMe cuando en el servidor haya una base de datos, un servidor de correo, un ejecutor de CI o una compilación con muchos paquetes. No pague un sobreprecio por un sitio web en caché ni por una aplicación cuyo tiempo se consuma en llamadas externas. Si no está seguro, probablemente el disco no sea su limitación, porque la mayoría de las cargas de trabajo pequeñas en VPS agotan antes la RAM o el ancho de banda.

Mida desde el primer día, mientras completa los primeros diez minutos en un VPS nuevo, y conserve la salida en un archivo. Una línea base le permite demostrar más adelante que el host se volvió más lento, en lugar de que el problema esté en su código. Prefiera proveedores que indiquen por escrito la clase de almacenamiento y cualquier límite de IOPS. Si un plan indica NVMe y una lectura con profundidad de cola 1 tarda 4 ms, está usando almacenamiento de red en un host equipado con NVMe. Es algo legítimo que se puede vender, pero no es lo mismo que se está comprando.

FAQ

¿NVMe siempre es más rápido que un SSD SATA en un VPS?

No. Con una profundidad de cola de 1, ambos ofrecen un rendimiento similar, de aproximadamente 80 a 150 microsegundos para una lectura de 4k, y un programa de un solo subproceso no puede distinguirlos. NVMe ofrece ventaja cuando hay muchas solicitudes en curso, porque AHCI proporciona una cola con una profundidad de 32 comandos, mientras que NVMe proporciona miles de colas más profundas. En un host compartido, la carga de otros invitados puede modificar la latencia más que el medio de almacenamiento. Por eso, mida su propio volumen con fio en lugar de basarse en el nombre del plan.

¿Cómo compruebo si mi VPS usa realmente NVMe?

No puede comprobarlo directamente, porque virtio oculta el dispositivo físico. lsblk muestra vda sin una cadena de modelo, nvme list no devuelve nada y /sys/block/vda/queue/rotational sólo informa de lo que anuncia el hipervisor. Mida el comportamiento en su lugar. Una lectura aleatoria de 4k con profundidad de cola de 1 y una latencia inferior a aproximadamente 0.3 ms indica almacenamiento flash local. Una latencia de varios milisegundos indica que hay un salto de red en la ruta. Las lecturas secuenciales que se detienen cerca de 550 MB/s indican un enlace SATA.

¿NVMe hace que mi sitio web cargue más rápido?

Normalmente no. Después de la primera solicitud, Linux sirve los archivos desde la caché de páginas en la RAM, por lo que el disco queda inactivo. En un VPS pequeño, la velocidad de carga suele estar limitada por el tiempo de CPU de la aplicación y por el ancho de banda. El disco vuelve a formar parte de la ruta crítica si el sitio escribe en cada solicitud. Por ejemplo, un carrito basado en una base de datos que confirma transacciones con frecuencia espera a que cada operación de vaciado termine.

¿Qué resultado de fio es bueno para un VPS?

En julio de 2026, un VPS pequeño con almacenamiento flash local suele ofrecer decenas de miles de IOPS de lectura aleatoria de 4k con una profundidad de cola de 32, y una latencia inferior a 0.3 ms con una profundidad de cola de 1. El almacenamiento de bloques en red suele ofrecer unos pocos miles de IOPS con una latencia de varios milisegundos. Ejecute la prueba tres veces en horas diferentes. Una gran variación entre las ejecuciones le informa de más que el promedio, porque muestra cuánto le afecta la actividad de los demás invitados del host.

¿Debería colocar mi base de datos en almacenamiento de bloques en red?

Puede hacerlo, y muchos servicios administrados lo hacen, pero la ruta de confirmación tiene ese coste. Cada operación de vaciado atraviesa la red, por lo que una sola conexión confirma menos transacciones pequeñas por segundo que en un almacenamiento flash local. A cambio, obtiene una durabilidad que sobrevive al host. Si elige almacenamiento en red para una base de datos con muchas escrituras, agrupe el trabajo en transacciones más grandes para que menos operaciones de vaciado transporten más filas.