--- title: "SSD vs NVMe vs HDD: rendimiento real y cuándo usar cada uno" description: "Compara discos HDD, SSD SATA y NVMe en IOPS, latencia y coste, aprende a identificarlos y medirlos con fio en Linux y elige el almacenamiento para cada carga." category: "Guía de Comparación" language: es source: https://cubepath.com/es/docs/guía-de-comparación/ssd-vs-nvme-vs-hdd-rendimiento-y-casos-de-uso updated: 2026-09-25 --- # SSD vs NVMe vs HDD: rendimiento real y cuándo usar cada uno El tipo de disco decide cuánto tarda una base de datos en confirmar una transacción, cuánto tarda en arrancar una máquina virtual y cuántos usuarios aguanta una aplicación antes de que el I/O sea el cuello de botella. En esta guía verás en qué se diferencian los discos duros mecánicos (HDD), los SSD SATA y los SSD NVMe, cómo identificar cuál tienes en un servidor Linux y cómo medir su rendimiento real con `fio` en Ubuntu 24.04. ## Resumen rápido Las cifras son rangos típicos de unidades actuales de gama servidor. Cada modelo concreto tiene su ficha técnica, pero el orden de magnitud entre tecnologías es estable: | Característica | HDD 7.200 rpm | SSD SATA | SSD NVMe | |---|---|---|---| | Interfaz | SATA o SAS | SATA III (6 Gb/s) | PCIe 3.0, 4.0 o 5.0 x4 | | Lectura secuencial | 150-280 MB/s | Hasta ~550 MB/s (límite de SATA) | ~3,5 GB/s (PCIe 3.0) a más de 12 GB/s (PCIe 5.0) | | IOPS aleatorias 4K | 100-200 | Decenas de miles | Cientos de miles a más de un millón | | Latencia de acceso | 4-10 ms | ~0,1 ms | Decenas de microsegundos | | Colas de comandos | 1 cola, 32 comandos (NCQ) | 1 cola, 32 comandos | Hasta 65.535 colas de 65.535 comandos | | Coste por TB | El más bajo | Medio | Medio-alto, cada vez más cerca del SATA | | Capacidad máxima habitual | Más de 20 TB | 8 TB | 30 TB o más en formatos U.2/E3.S | La diferencia que más se nota en servidores no es la velocidad secuencial, sino las IOPS aleatorias y la latencia. Un HDD mueve la cabeza física para cada lectura aleatoria; un SSD no tiene piezas móviles, y NVMe además elimina el cuello de botella de la interfaz SATA/AHCI, diseñada para discos mecánicos. ## En qué se diferencian ### HDD Guarda los datos en platos magnéticos que giran. Cada acceso aleatorio cuesta el tiempo de mover el cabezal y esperar a que el sector pase por debajo, de ahí sus pocas IOPS. En lecturas y escrituras secuenciales grandes rinde de forma aceptable, y su coste por TB sigue siendo el más bajo. ### SSD SATA Usa memoria flash NAND y la misma interfaz que los discos duros. Elimina la latencia mecánica, pero el protocolo AHCI y el enlace de 6 Gb/s limitan el ancho de banda a unos 550 MB/s y la profundidad de cola a 32 comandos. ### SSD NVMe Usa la misma memoria flash conectada directamente al bus PCIe con un protocolo diseñado para ella. Con muchas colas paralelas, un servidor con muchos núcleos puede lanzar I/O desde cada uno sin contención. Es el formato estándar en servidores modernos, tanto en M.2 como en U.2 o E3.S. ## Requisitos previos Para seguir la parte práctica necesitas: - Un servidor con Ubuntu 24.04 LTS, físico o virtual. - Un usuario no root con privilegios `sudo`. - Al menos 2 GB libres en el sistema de archivos donde vayas a hacer las pruebas. ## Paso 1: Identificar el tipo de disco `lsblk` muestra si el kernel considera el disco rotacional (`ROTA=1`) y por qué bus está conectado: ```bash lsblk -d -o NAME,ROTA,TRAN,SIZE,MODEL ``` En un servidor físico con los tres tipos verías algo así: ```output NAME ROTA TRAN SIZE MODEL sda 1 sata 16.4T ST18000NM000J-2TV103 sdb 0 sata 1.7T SAMSUNG MZ7L31T9HBLT-00A07 nvme0n1 0 nvme 3.5T SAMSUNG MZQL23T8HCLS-00A07 ``` - `sd*` con `ROTA=1`: disco mecánico. - `sd*` con `ROTA=0` y `TRAN=sata`: SSD SATA. - `nvme*`: SSD NVMe. > Nota: en una máquina virtual el disco aparece como `vda` o `sda` sin modelo real, y `ROTA` depende de cómo lo exponga el hipervisor, no del disco físico. En un VPS, la única forma fiable de saber cómo rinde tu almacenamiento es medirlo, como en el paso 3. ## Paso 2: Revisar la salud del disco En servidores físicos, el estado SMART indica el desgaste de un SSD y los sectores reasignados de un HDD. Instala las herramientas: ```bash sudo apt install smartmontools nvme-cli ``` Para un disco SATA (HDD o SSD): ```bash sudo smartctl -H -A /dev/sda ``` Busca `SMART overall-health self-assessment test result: PASSED` y, en HDD, que `Reallocated_Sector_Ct` y `Current_Pending_Sector` estén a 0. Para un NVMe: ```bash sudo nvme smart-log /dev/nvme0 ``` ```output critical_warning : 0 temperature : 38 °C (311 K) available_spare : 100% percentage_used : 3% data_units_written : 91,442,120 (46.82 TB) media_errors : 0 ``` `percentage_used` es la estimación del fabricante de la vida consumida, y `data_units_written` permite compararla con los TBW (terabytes escritos) de la ficha técnica. `critical_warning` debe ser 0. Estos comandos no funcionan dentro de un VPS porque el disco es virtual. ## Paso 3: Medir el rendimiento con fio `fio` es la herramienta estándar para medir I/O en Linux. Evita `dd` para esto: solo mide escritura secuencial con un único hilo y, sin las opciones adecuadas, mide la caché de la RAM. ```bash sudo apt install fio ``` Crea un directorio de pruebas en el sistema de archivos que quieres medir: ```bash mkdir -p ~/fio-test cd ~/fio-test ``` ### Lectura aleatoria 4K (IOPS) Es la prueba que mejor separa las tres tecnologías y la que más se parece a una base de datos leyendo índices: ```bash fio --name=randread --filename=fio.dat --size=1G --rw=randread --bs=4k \ --ioengine=libaio --direct=1 --iodepth=32 --numjobs=4 \ --runtime=60 --time_based --group_reporting ``` `--direct=1` evita la caché de páginas del kernel, e `--iodepth=32` con `--numjobs=4` mantiene suficientes peticiones en vuelo para que un SSD muestre su capacidad. Fíjate en la línea de resumen: ```output read: IOPS=182k, BW=711MiB/s (746MB/s)(41.7GiB/60001msec) ``` Como referencia, un HDD dará del orden de cientos de IOPS, un SSD SATA decenas de miles y un NVMe cientos de miles. ### Escritura síncrona con fsync (latencia) Las bases de datos confirman cada transacción con `fsync`, así que lo que importa es la latencia de una escritura aislada, no el ancho de banda: ```bash fio --name=fsync --filename=fio.dat --size=1G --rw=randwrite --bs=4k \ --ioengine=sync --iodepth=1 --numjobs=1 --fsync=1 \ --runtime=60 --time_based ``` Revisa la sección `clat` (latencia de finalización) y los percentiles: ```output write: IOPS=9120, BW=35.6MiB/s (37.4MB/s)(2138MiB/60001msec) clat percentiles (usec): | 50.00th=[ 93], 99.00th=[ 178], 99.90th=[ 416] ``` Una unidad con condensadores de protección ante cortes (habitual en SSD de centro de datos) confirma estas escrituras en decenas de microsegundos. Un SSD de consumo puede tardar milisegundos, y un HDD está en ese mismo rango o peor. ### Lectura secuencial (ancho de banda) Útil para copias de seguridad, streaming de vídeo o carga de datos masiva: ```bash fio --name=seqread --filename=fio.dat --size=1G --rw=read --bs=1M \ --ioengine=libaio --direct=1 --iodepth=16 --numjobs=1 \ --runtime=30 --time_based ``` Cuando termines, borra el archivo de pruebas: ```bash rm -f ~/fio-test/fio.dat ``` > Advertencia: nunca apuntes `--filename` a un dispositivo de bloques como `/dev/sda` en una prueba de escritura. `fio` escribiría directamente sobre el disco y destruiría el sistema de archivos. ## Paso 4: Comprobar TRIM y el planificador de I/O Los SSD necesitan saber qué bloques ya no están en uso para mantener el rendimiento. Ubuntu activa por defecto un temporizador semanal que ejecuta `fstrim`: ```bash systemctl status fstrim.timer ``` Debe aparecer como `active (waiting)`. Para lanzarlo a mano y ver cuánto espacio se liberó: ```bash sudo fstrim -av ``` El planificador de I/O también cambia según el tipo de disco. Para NVMe el kernel usa `none`, porque el propio dispositivo gestiona las colas mejor que el sistema operativo: ```bash cat /sys/block/nvme0n1/queue/scheduler ``` ```output [none] mq-deadline ``` Para HDD suele ser `mq-deadline`, que agrupa peticiones para reducir los movimientos del cabezal. Los valores por defecto de Ubuntu son correctos para cada tipo y no hace falta cambiarlos. ## Casos de uso ### HDD - Copias de seguridad, archivado y almacenamiento de objetos donde prima el coste por TB. - Vídeo, logs históricos y otros datos que se leen o escriben de forma secuencial. - Capas "frías" en sistemas como Ceph, ZFS o MinIO, idealmente con SSD como caché o para metadatos. No es adecuado para sistemas operativos de servidores, bases de datos ni máquinas virtuales. ### SSD SATA - Servidores web y de aplicaciones con carga moderada. - Ampliar servidores antiguos sin ranuras M.2 ni U.2. - Almacenamiento de capacidad media donde NVMe no aporta porque la red es el límite (por ejemplo, un NAS con enlace de 1 Gb/s). ### SSD NVMe - Bases de datos (MySQL, PostgreSQL, Redis con persistencia, ClickHouse). - Hipervisores con muchas máquinas virtuales compartiendo el mismo disco. - Compilación, CI/CD, contenedores y cualquier carga con mucho I/O aleatorio o paralelo. - Almacenamiento distribuido de alto rendimiento. ## RAID y redundancia Ningún tipo de disco es inmune a fallos. En servidores físicos: - **RAID 1 o RAID 10** es lo habitual para bases de datos y sistemas operativos en SSD y NVMe: buen rendimiento de escritura y reconstrucción rápida. - **RAID 5 o RAID 6** con HDD de gran capacidad tiene reconstrucciones muy largas (días en discos de 20 TB) durante las que el array está degradado. Con discos grandes, RAID 6 o RAID 10 es más seguro. - En Linux, `mdadm` o ZFS funcionan igual de bien con NVMe que con discos SATA, sin necesidad de controladora hardware. RAID no sustituye a las copias de seguridad: protege frente al fallo de un disco, no frente a un borrado accidental o un ransomware. ## Cuál elegir **Elige HDD cuando:** - Necesitas muchos terabytes al menor coste y el acceso es secuencial o poco frecuente. **Elige SSD SATA cuando:** - El hardware no admite NVMe o el rendimiento de SATA es más que suficiente para la carga. **Elige NVMe cuando:** - Ejecutas bases de datos, máquinas virtuales o cualquier servicio sensible a la latencia. - Estás comprando hardware nuevo: la diferencia de precio con SATA es pequeña y la de rendimiento, grande. ## Conclusión Para el disco del sistema y los datos activos de un servidor, NVMe es hoy la opción razonable, mientras que el HDD queda para capacidad barata en copias de seguridad y archivado. Más que fiarte de las cifras de la ficha técnica, mide tu almacenamiento con `fio` usando el patrón de acceso de tu aplicación, especialmente la latencia con `fsync` si alojas una base de datos. Como siguientes pasos, programa una revisión periódica de SMART con `smartd`, configura un RAID 1 con `mdadm` en servidores físicos y define una política de copias de seguridad fuera del servidor.