NVMe vs SSD: qué diferencia hace realmente en un VPS

SSD SATA y NVMe no son lo mismo

Un SSD SATA utiliza una interfaz creada originalmente para discos mecánicos. NVMe fue diseñado para memoria no volátil sobre PCI Express y admite muchas colas y operaciones paralelas con menor latencia.

Las cifras máximas del fabricante no se trasladan directamente a un VPS. El mismo dispositivo físico atiende varias máquinas, el hipervisor puede limitar IOPS y el proveedor puede usar RAID, caché o almacenamiento distribuido.

Las métricas que sí importan

• Latencia: tiempo que tarda una operación individual.
• IOPS: cantidad de operaciones de entrada/salida por segundo.
• Rendimiento secuencial: megabytes por segundo al leer o escribir bloques grandes.
• Profundidad de cola: operaciones pendientes que el almacenamiento procesa en paralelo.
• Variabilidad: diferencia entre el rendimiento normal y los peores momentos.

Una web dinámica suele beneficiarse más de baja latencia y buen acceso aleatorio que de una cifra enorme de lectura secuencial.

Dónde se nota NVMe

Las bases de datos realizan numerosas lecturas y escrituras pequeñas. WooCommerce registra pedidos, sesiones y metadatos; PostgreSQL escribe WAL; Redis puede persistir snapshots; Docker extrae capas y crea archivos. En estos escenarios, reducir la espera de almacenamiento mejora el tiempo de respuesta.

También se nota al instalar dependencias, compilar proyectos, restaurar backups y procesar muchas imágenes. Para una web estática servida desde RAM o CDN, la diferencia puede ser mínima durante las visitas normales.

Dónde no resolverá el problema

NVMe no corrige consultas SQL sin índices, falta de RAM, CPU saturada, llamadas lentas a APIs externas ni latencia geográfica. Tampoco garantiza recursos exclusivos. Un plan puede anunciar NVMe y limitar cada VPS a pocas IOPS.

Antes de migrar por el tipo de disco, revisa CPU, memoria, iowait y latencia de la aplicación.

Cómo medir un VPS

fio permite pruebas reproducibles. Instálalo en Ubuntu o Debian y ejecuta una prueba temporal fuera de las horas críticas:

sudo apt update && sudo apt install -y fio
fio --name=random-read --filename=fio.test --size=1G --rw=randread \
  --bs=4k --iodepth=32 --direct=1 --runtime=30 --time_based
rm fio.test

Mira IOPS y latencia, no solo ancho de banda. La prueba consume recursos y puede afectar otros servicios; nunca uses tamaños que llenen el disco ni la ejecutes sin autorización en infraestructura compartida administrada.

Para observar actividad real:

iostat -xz 1

Un porcentaje alto de iowait y latencias sostenidas pueden señalar almacenamiento como cuello de botella.

Comparación práctica

Capacidad, velocidad y respaldo

No sacrifiques capacidad o backups solo por la etiqueta NVMe. Mantén espacio libre para actualizaciones, logs y tareas temporales. Pregunta qué ocurre si falla una unidad, qué RAID existe y si los snapshots viven en almacenamiento independiente.

Terranode publica almacenamiento NVMe en sus planes VPS KVM. Para dimensionar correctamente, combina el disco con la RAM que necesita tu VPS y la cantidad de CPU que realmente exige la aplicación.

La etiqueta del disco no describe el servicio completo

NVMe define un protocolo; no dice cuántas operaciones recibirá tu VPS, cuánta caché existe ni cuántos vecinos comparten el arreglo. Un proveedor puede usar unidades NVMe excelentes y aplicar un límite de IOPS bajo. Otro puede ofrecer SSD SATA en un arreglo bien dimensionado y entregar una experiencia más estable para una carga modesta.

Por eso conviene pedir información sobre la plataforma, no una marca aislada: límites sostenidos y de ráfaga, redundancia, política cuando el nodo está ocupado y latencia observada en producción. La consistencia importa más que un pico de laboratorio. Una base de datos sufre cuando las operaciones habituales tardan cinco veces más durante minutos, aunque el promedio diario parezca bueno.

El sistema de almacenamiento también puede ser local o distribuido. El local evita parte de la latencia de red; el distribuido puede facilitar redundancia y movimiento entre nodos. Ningún diseño gana siempre. Lo importante es que el proveedor explique qué fallo tolera y cómo recupera una máquina.

IOPS frente a megabytes por segundo

Copiar un archivo grande utiliza operaciones secuenciales y suele expresarse en MB/s. Una base de datos o un árbol con miles de archivos pequeños genera acceso aleatorio y se entiende mejor con IOPS y latencia. Dos discos que copian una imagen a velocidad parecida pueden comportarse de forma opuesta al resolver consultas concurrentes.

El tamaño del bloque cambia el resultado. Una prueba de 1 MB favorece transferencia secuencial; bloques de 4 KB se acercan a muchas operaciones de base de datos. La profundidad de cola también importa: un dispositivo NVMe puede mostrar su capacidad cuando recibe muchas solicitudes simultáneas, mientras una aplicación que espera cada operación una por una depende más de la latencia individual.

No mezcles resultados obtenidos con parámetros diferentes. Documenta lectura o escritura, aleatoria o secuencial, tamaño de bloque, profundidad, duración y acceso directo. Sin esa ficha, decir “mi disco da 2 GB/s” aporta poco a una decisión de hosting.

Cómo hacer una prueba sin poner en riesgo producción

Una prueba sintética escribe y lee datos deliberadamente; puede competir con la aplicación y llenar espacio. Crea un archivo limitado en un directorio con capacidad suficiente, ejecuta durante poco tiempo fuera del pico y elimínalo al terminar. No pruebes sobre el archivo de una base ni sobre un volumen casi lleno.

Este ejemplo mezcla lecturas aleatorias y limita el archivo de prueba:

fio --name=mixed-4k --filename=/var/tmp/fio-test.dat --size=1G \
  --rw=randrw --rwmixread=70 --bs=4k --iodepth=16 \
  --direct=1 --runtime=60 --time_based --group_reporting
rm -f /var/tmp/fio-test.dat

Lee los percentiles de latencia además del promedio. Si la mayoría responde rápido pero el percentil alto se dispara, los usuarios pueden notar pausas intermitentes. Repite en varios horarios con exactamente el mismo comando. Una única ejecución mide ese minuto, no la calidad permanente del servicio.

Para producción, las métricas de la aplicación son el control final: tiempo de consulta, duración de transacciones, cola de entrada/salida y tiempo total de la petición. fio ayuda a caracterizar el disco; no reemplaza una prueba del sitio.

Interpretar iowait y la saturación

iostat -xz 1 muestra actividad por dispositivo. Observa latencia de lectura y escritura, profundidad de cola y utilización durante el problema. Un iowait alto indica que la CPU permanece ociosa esperando entrada/salida, pero una cifra baja no demuestra que el disco sea rápido: una aplicación de un solo hilo puede estar bloqueada mientras otras CPU siguen libres.

Combina la observación con procesos. Una copia puede saturar escrituras; el motor de base de datos puede emitir lecturas aleatorias; los logs pueden crecer por un error repetido. Identificar al emisor evita culpar al dispositivo por trabajo innecesario.

La presión de memoria también puede aparentar un fallo de disco. Cuando falta RAM, Linux lee y escribe swap, expulsa caché y vuelve a cargar archivos. Cambiar SATA por NVMe puede suavizar el síntoma, pero la solución es corregir la capacidad o el proceso que consume memoria.

Bases de datos: cuándo la menor latencia sí cambia la respuesta

Una consulta atraviesa índices, buffers y, si el dato no está en memoria, almacenamiento. NVMe aporta cuando el conjunto activo supera la RAM, hay escrituras frecuentes o muchas transacciones esperan confirmación. Los registros de transacciones —WAL en PostgreSQL y redo logs en InnoDB— son sensibles a la latencia de escritura porque protegen la durabilidad.

Antes de migrar, revisa planes de consulta e índices. Una lectura completa de millones de filas seguirá siendo cara en el disco más rápido; un índice correcto puede evitar casi todo ese trabajo. Aumentar RAM para mantener el conjunto activo en caché a veces produce más beneficio que cambiar de interfaz.

Para comparar, captura consultas representativas y su distribución de tiempos, no solo el promedio. Ejecuta la misma versión, datos y configuración en ambos entornos. Si cambias a la vez CPU, memoria, región y disco, sabrás que mejoró el servidor, pero no cuánto aportó NVMe.

WordPress y WooCommerce no ejercen la misma presión

Un WordPress corporativo con caché de página entrega HTML sin consultar la base en la mayoría de visitas. Allí la diferencia entre SSD SATA y NVMe puede quedar escondida detrás de la red y el navegador. Se nota más al actualizar plugins, regenerar imágenes o trabajar en el panel que al servir una página cacheada.

WooCommerce ejecuta operaciones dinámicas para carrito, sesión, inventario y pedidos. Esas rutas consultan y escriben tablas aunque el catálogo público esté cacheado. NVMe puede reducir esperas, sobre todo durante concurrencia, pero no arregla una tabla de acciones programadas desbordada ni plugins que generan cientos de consultas por petición.

Mide el checkout de extremo a extremo. Si el tiempo se pierde esperando una pasarela externa, el disco local no interviene. Si la base acumula cola y latencia, optimizar índices, caché de objetos y almacenamiento sí tiene sentido.

Contenedores, despliegues y muchos archivos pequeños

Docker descarga capas grandes, pero al extraerlas crea numerosos archivos. Composer, npm y compiladores hacen algo parecido. NVMe reduce el tiempo de instalación y despliegue cuando hay muchas operaciones pequeñas, una ventaja relevante en integración continua o servidores que recrean contenedores con frecuencia.

En producción, los logs de varios contenedores pueden convertirse en una corriente constante de escrituras. La solución no es depender indefinidamente de un disco más rápido: configura rotación, niveles de registro y retención. Si una aplicación escribe cada evento de depuración, terminará consumiendo capacidad además de IOPS.

Los volúmenes de bases de datos deben tratarse aparte de las capas efímeras. Haz backups consistentes y verifica restauraciones. Una imagen de contenedor puede volver a descargarse; el volumen con pedidos o flujos no.

Capacidad libre, TRIM y degradación

Los SSD necesitan margen para gestionar bloques y mantener rendimiento. Desde el sistema huésped no controlas el dispositivo físico ni siempre puedes saber cómo el proveedor aplica TRIM, pero sí puedes evitar llenar tu volumen. Un sistema al 95 % también falla por logs, actualizaciones y temporales aunque el hardware sea NVMe.

Define alertas antes de llegar al límite y conserva espacio para una restauración, una actualización o una exportación. Investiga crecimientos inesperados con herramientas de uso de disco antes de ampliar a ciegas. Borrar logs manualmente sin corregir su rotación solo aplaza el siguiente incidente.

La capacidad contratada, el rendimiento y la protección son decisiones diferentes. Elegir un plan con menos espacio solo por obtener NVMe puede ser contraproducente si obliga a guardar backups en el mismo volumen o impide mantener una copia previa al despliegue.

Redundancia no significa backup

Un arreglo RAID o un almacenamiento replicado mantiene el servicio ante ciertos fallos físicos. Replica también un borrado, una corrupción lógica y un cifrado malicioso. El snapshot del proveedor puede acelerar una reversión, pero si está ligado a la misma cuenta o región no cubre todos los escenarios.

Mantén al menos una copia externa y prueba recuperar datos. Al evaluar el proveedor pregunta si el almacenamiento es redundante, pero formula por separado las preguntas de backup: frecuencia, retención, ubicación, granularidad y tiempo de restauración.

La velocidad de restauración también depende del disco. Si el objetivo es recuperar cientos de gigabytes en una ventana corta, prueba el proceso completo; no extrapoles desde la velocidad nominal de la unidad.

Cuándo pagar por NVMe y cuándo priorizar otra mejora

Prioriza NVMe para bases con actividad, tiendas dinámicas, CI, búsquedas, colas persistentes y cargas con muchos archivos pequeños. También es una buena elección general cuando la diferencia de precio no obliga a sacrificar RAM, backup o región.

Prioriza RAM si el sistema intercambia y el conjunto activo no cabe en memoria. Prioriza CPU si PHP, compilación o cifrado mantienen los núcleos ocupados. Prioriza una región cercana si la latencia de red domina. Y corrige la aplicación cuando las consultas, llamadas externas o plugins explican el tiempo.

La elección final puede expresarse como una hipótesis verificable: “esperamos reducir la latencia de escritura de la base durante el pico”. Define la métrica antes de migrar y compárala después. Si solo compras porque la palabra NVMe parece moderna, no tendrás forma de saber si la inversión resolvió algo.

Lista de comprobación para comparar dos VPS

Usa la misma imagen del sistema, versión de aplicación, datos y parámetros de prueba. Ejecuta varias veces en horarios comparables. Registra IOPS, percentiles de latencia, rendimiento secuencial y, sobre todo, tiempos de operaciones reales como abrir el panel, completar checkout o restaurar una copia.

Comprueba el comportamiento sostenido y la variabilidad. Confirma capacidad, redundancia, snapshots, backups y procedimiento de soporte. Finalmente calcula el coste total: plan, almacenamiento externo, tiempo de migración y margen que conservas para RAM y CPU.

Ese proceso distingue una mejora real de una cifra de marketing y deja evidencia para la siguiente decisión de capacidad.

Latencia de cola: por qué el disco empeora antes de llenarse

Un dispositivo puede atender cada operación rápidamente mientras recibe poco trabajo. Cuando llegan más solicitudes de las que procesa, se forma una cola y el tiempo total crece. La aplicación nota esa espera antes de alcanzar la capacidad máxima del volumen. Backups, logs y consultas compiten aunque pertenezcan a servicios distintos.

Observa la profundidad de cola junto con latencia. Si ambas suben durante una tarea, limita su tasa o cambia el horario. Dar mayor prioridad al proceso interactivo puede proteger usuarios mientras el trabajo secundario termina más despacio. Si la cola aparece con carga normal, necesitas reducir entrada/salida o aumentar capacidad de almacenamiento.

NVMe suele sostener más operaciones paralelas, pero no hace infinita la cola. Un límite del proveedor puede dominar mucho antes que el hardware. Por eso las pruebas sostenidas y las métricas del pico son esenciales.

Evita ejecutar varios trabajos intensivos juntos: volcado, compresión, escaneo y rotación a la misma hora pueden producir una caída nocturna. Escalonarlos es una mejora gratuita y conserva los backups.

Sincronización de escrituras y durabilidad

Las bases no solo escriben datos; confirman que registros críticos llegaron a almacenamiento estable antes de responder. Esa sincronización protege pedidos y transacciones ante un apagado, pero expone la latencia de escritura. Desactivar garantías para ganar un benchmark puede convertir una caída en pérdida o corrupción.

No compares una prueba con caché de escritura sin aclarar cuándo los datos se consideran persistentes. El sistema operativo, controlador, hipervisor y dispositivo participan. En un VPS, debes confiar en que la plataforma respeta las barreras y dispone de protección adecuada; pregunta al proveedor en lugar de cambiar opciones de durabilidad a ciegas.

Para cargas críticas, mide transacciones reales con su configuración segura. Un NVMe bien operado puede reducir espera sin sacrificar confirmación. El objetivo no es obtener la cifra más alta, sino mantener la garantía requerida dentro del tiempo aceptable.

Almacenamiento local frente a almacenamiento distribuido

NVMe local ofrece baja latencia porque está conectado al nodo, pero mover una VM puede requerir copiar datos o depender de replicación adicional. Un sistema distribuido almacena bloques en varios nodos y facilita tolerancia, a cambio de red y más capas. Ambos pueden anunciar SSD o NVMe.

Pregunta qué ocurre al fallar el host o una unidad, si existe réplica y cuánto tarda la recuperación. No supongas que “local” significa sin redundancia ni que “distribuido” significa backup. La arquitectura puede tolerar hardware y seguir replicando un borrado lógico.

Tu carga decide el equilibrio. Una base muy sensible a latencia puede favorecer almacenamiento local protegido; una plataforma que prioriza movilidad puede aceptar la latencia del distribuido. Sin información del proveedor, una etiqueta de interfaz no permite compararlos.

Migrar datos a un nuevo disco sin una copia incoherente

Para archivos estáticos, sincroniza una copia inicial, valida y realiza una segunda pasada durante una ventana breve. Para bases, usa su mecanismo de backup o replicación; copiar archivos en caliente puede combinar páginas de momentos distintos. Verifica checksums o recuentos cuando corresponda.

Antes del cambio DNS o arranque final, prueba permisos, propietarios, montajes y espacio. Ejecuta el flujo real y un reinicio. Conserva el origen sin aceptar nuevas escrituras durante la reversión; volver a una copia antigua después de recibir pedidos crea pérdida silenciosa.

Registra cuánto tardó la copia y restauración. Ese tiempo permite calcular futuras ventanas y objetivos de recuperación. La migración a NVMe solo está terminada cuando los datos son coherentes y el procedimiento de backup continúa funcionando.

Mantener el rendimiento después de la migración

Guarda la línea base de latencia e IOPS y configura alertas sobre espacio, espera y errores. Revisa después de cambios de base, contenedores o retención de logs. Un servidor rápido al principio puede degradarse porque el conjunto de datos creció o porque una tarea empezó a competir.

Controla archivos borrados que siguen abiertos, logs sin rotación y snapshots acumulados. Mantén margen y prueba backups fuera del volumen. Si aparece variabilidad, compara el mismo flujo por horario antes de concluir que el hardware falló.

La mejora más valiosa es sostenible. NVMe debe reducir la espera de la aplicación durante el trabajo real y seguir haciéndolo meses después, no solo producir una captura llamativa el día de contratación.

Conserva además el comando exacto de prueba, la versión de fio, el tamaño del volumen y las condiciones de carga. Al comparar meses después, usa un archivo temporal equivalente y no el directorio de producción. Relaciona el resultado con una acción del usuario y con la latencia de la base. Si el benchmark cambia pero la aplicación no, revisa caché y patrón de acceso antes de migrar otra vez. Si ambos empeoran en el mismo horario, entrega al proveedor las series completas para investigar saturación o límites.