La pregunta solía ser sencilla: ¿puedes permitirte bare metal o te quedas con una VM? Hoy es más precisa. A medida que los pipelines de inferencia de IA, los análisis en tiempo real y las arquitecturas orientadas a eventos imponen presupuestos de latencia más estrictos a los backends de bases de datos, la brecha entre bare metal y VDS ya no es solo una conversación de costos. Es un punto de inflexión de rendimiento que determina si tu latencia p99 se mantiene dentro del SLA o se desvía silenciosamente por encima de él.

Este artículo analiza la mecánica real: dónde aterriza la sobrecarga del hipervisor, cuánto te cuesta la ruta de almacenamiento y cómo interpretar los números con honestidad, sin filtros de marketing.

Qué separa al bare metal del VDS a nivel de hardware

Un servidor bare metal es una máquina física dedicada a un único inquilino. Tu sistema operativo se comunica directamente con la CPU, la RAM, el NVMe local y la NIC. No hay ningún hipervisor en medio. Un VDS corre sobre una capa de hipervisor, típicamente KVM, que divide un host físico en múltiples guests aislados. Cada guest ejecuta su propio sistema operativo y parece dedicado, pero el hipervisor media cada interacción con el hardware.

Esa mediación es donde entra la latencia. Para la mayoría de las cargas de trabajo de propósito general, los hipervisores modernos mantienen la sobrecarga entre un 2 y un 10 por ciento, lo que es un intercambio completamente razonable por la flexibilidad de aprovisionamiento y la densidad que ofrece el VDS. Las cargas de bases de datos no son la mayoría de las cargas de trabajo.

Tres mecanismos que perjudican el rendimiento de bases de datos en VDS

CPU steal time

El steal time es el retraso que experimenta una vCPU mientras espera que la CPU física esté disponible. Las métricas de utilización estándar no lo capturan, lo que lo hace insidioso: tu monitoreo muestra un 40 por ciento de uso de CPU mientras la latencia de tus consultas está disparándose. Bajo carga OLTP sostenida, los picos de steal time se traducen directamente en picos de latencia de cola. Los verás en tus números p99 y p99.9, no en tus promedios.

Desalineación NUMA

Los servidores modernos son máquinas multi-socket con arquitecturas de acceso no uniforme a memoria (NUMA). Si la memoria de una VM se asigna desde el Socket 0 pero su vCPU se programa en el Socket 1, cada acceso a memoria cruza la interconexión entre sockets. Esa penalización por acceso remoto a memoria agrega decenas de microsegundos por operación. En bare metal puedes anclar el proceso de tu base de datos a un nodo NUMA y mantener la memoria local. Dentro de una VM, el scheduler del hipervisor toma esa decisión, y no siempre es óptima para tu carga de trabajo.

Vecino ruidoso en recursos micro-arquitectónicos compartidos

Incluso un VDS bien aislado en un host físico dedicado comparte la caché L3 de CPU y el ancho de banda de memoria con los demás guests en ese host. Una VM vecina que ejecuta una carga de trabajo que agota la caché, como transcodificación de video o un trabajo de análisis masivo, puede expulsar el conjunto de trabajo activo de tu base de datos de la caché. La siguiente consulta falla en caché y va al almacenamiento. Este no es un riesgo teórico; es el mecanismo detrás de la varianza de rendimiento que hace que la latencia p99 sea impredecible en infraestructura virtualizada.

La latencia p99 es donde se concentra la ventaja del bare metal. El rendimiento mediano en VDS a menudo parece aceptable; el peor uno por ciento de las solicitudes es donde aparecen los picos de steal time y la expulsión de caché, y esas son exactamente las solicitudes que tus usuarios notan.

La ruta de almacenamiento: donde el VDS pierde terreno más rápido

En bare metal, las escrituras del Write-Ahead Log de tu base de datos van directamente por PCIe a una unidad NVMe local. La latencia nativa de NVMe se sitúa alrededor de 20 a 50 microsegundos. En un VDS que usa virtio-scsi o virtio-blk, la solicitud de I/O recorre una ruta de software antes de llegar al dispositivo físico. Esa capa de software agrega aproximadamente 10 a 30 microsegundos por operación. En NVMe, eso puede efectivamente duplicar la latencia de almacenamiento observada.

Hay un segundo problema específico del VDS en la nube: los proveedores frecuentemente limitan los IOPS por instancia para garantizar un uso equitativo, independientemente del hardware de disco subyacente. Un plan anunciado como respaldado por NVMe puede estar limitado a 10.000 IOPS a nivel de instancia, lo cual es inferior a lo que entrega un SSD SATA nativo sin restricciones. Estás pagando por NVMe y recibiendo un rendimiento equivalente a SATA porque la cuota se aplica por encima del hardware.

Los datos de benchmarks son coherentes con estos mecanismos. La comparación KVM de CubePath muestra bare metal a 28.450 transacciones por segundo con una latencia en el percentil 95 de 18,3 ms, frente a KVM con 25.630 TPS y un percentil 95 de 21,5 ms, un aumento del 17,5 por ciento en la latencia de cola. Benchmarks más amplios de PostgreSQL que comparan bare metal con instancias virtualizadas equivalentes muestran un TPS entre un 30 y un 40 por ciento mayor en bare metal. NVMe accedido de forma nativa frente a una ruta virtualizada entrega 3,8 veces más TPS en MySQL y una latencia p99 13,9 veces menor en comparación con configuraciones de SSD SATA; a profundidad de cola 32, donde suelen operar las bases de datos, NVMe proporciona alrededor de 650.000 IOPS frente a un techo de 95.000 en SATA.

Cuándo el VDS es la respuesta correcta de todas formas

El bare metal no es la respuesta correcta por defecto. El VDS gana en velocidad de aprovisionamiento, costo con menor utilización y flexibilidad para cargas de trabajo que no saturan el hardware. Una réplica de lectura que maneja 200 consultas por segundo no necesita hardware dedicado. Un entorno de staging, una base de datos de reportes o el almacén embebido de un microservicio casi con certeza tampoco. El VDS tiene sentido cuando tu conjunto de trabajo cabe cómodamente en caché, tu combinación de consultas es mayoritariamente de lectura y tolera varianza ocasional de latencia, y necesitas escalar horizontalmente en lugar de verticalmente.

El punto de inflexión llega típicamente cuando el conjunto de trabajo de tu base de datos se acerca o supera la caché disponible, cuando estás ejecutando OLTP con alta concurrencia, o cuando un SLA downstream requiere una latencia de almacenamiento consistente por debajo del milisegundo. En ese punto, el costo de la sobrecarga del VDS no es la diferencia de precio de la instancia; es el tiempo de ingeniería dedicado a ajustar una variabilidad que el bare metal elimina de forma estructural.

Qué significa esto para cargas de trabajo de bases de datos con IA y GPU

El mercado de bare metal crece a una tasa compuesta anual superior al 20 por ciento, y el motor no es la nostalgia por el hardware físico. Son las cargas de trabajo de IA y GPU las que crean nuevos requisitos de latencia en el nivel de bases de datos. Un pipeline de inferencia GPU que procesa una solicitud en 15 milisegundos no puede permitirse un backend de base de datos con una latencia p99 de 30 ms. Los feature stores, las bases de datos vectoriales y las búsquedas de embeddings en tiempo real se ubican directamente en la ruta crítica de inferencia.

En DIVERSITY operamos infraestructura de inferencia y entrenamiento GPU, y el patrón que vemos de forma consistente es que los equipos optimizan la capa de model serving y luego descubren que el backend de base de datos es el verdadero cuello de botella. La GPU está inactiva, esperando una consulta. Mover la base de datos a bare metal con NVMe local y colocarla en el mismo datacenter que los nodos de inferencia suele reducir esa espera más de lo que cualquier optimización adicional del modelo lograría.

Cómo tomar la decisión: un marco práctico

  • Mide primero tu latencia p99 y p99.9. Si tu latencia de cola ya está dentro del presupuesto y es estable, el VDS probablemente sea suficiente. Si es variable o está por encima del objetivo, el hipervisor y la ruta de almacenamiento son probablemente los responsables.
  • Mide el steal time de forma explícita. En guests Linux, top y vmstat muestran el steal time directamente. Un steal sostenido por encima del 5 por ciento bajo carga es una señal de que el host físico está saturado.
  • Verifica tu asignación de IOPS, no solo el tipo de almacenamiento anunciado. Pregunta a tu proveedor el límite de IOPS por instancia. Si está por debajo de 50.000, no estás obteniendo rendimiento NVMe independientemente de lo que diga la ficha técnica.
  • Coloca el cómputo y la base de datos en el mismo datacenter. El almacenamiento conectado por red a través de un fabric de datacenter agrega entre 0,5 y 2 milisegundos de latencia de ida y vuelta por I/O. El NVMe local elimina eso por completo.
  • Dimensiona el conjunto de trabajo frente a la RAM disponible. Si tus datos activos caben en memoria, la latencia de almacenamiento importa menos. Si no es así, bare metal con NVMe local rápido es la única ruta confiable hacia un rendimiento p99 consistente.

La elección entre bare metal y VDS no tiene que ver con prestigio ni con conservadurismo. Se trata de hacer coincidir las características de rendimiento del hardware con lo que tu base de datos realmente necesita. Para cargas de trabajo sensibles a la latencia, la sobrecarga del hipervisor es real, medible y se concentra exactamente donde más duele: en la latencia de cola que determina si tu aplicación se siente rápida o poco confiable.