The question used to be simple: can you afford bare metal, or do you take a VM? Today it is sharper. As AI inference pipelines, real-time analytics, and event-driven architectures push tighter latency budgets onto database backends, the gap between bare metal and VDS is no longer just a cost conversation. It is a performance inflection point that determines whether your p99 latency stays within SLA or quietly drifts past it.

This post works through the actual mechanics: where hypervisor overhead lands, what the storage path costs you, and how to read the numbers honestly rather than through vendor marketing.

What separates bare metal from VDS at the hardware level

A bare metal server is a physical machine dedicated to a single tenant. Your OS talks directly to the CPU, RAM, local NVMe, and NIC. No hypervisor sits in between. A VDS runs on a hypervisor layer, typically KVM, that partitions a physical host into multiple isolated guests. Each guest runs its own OS and appears dedicated, but the hypervisor mediates every interaction with hardware.

That mediation is where latency enters. For most general-purpose workloads, modern hypervisors keep overhead to 2 to 10 percent, and that is an entirely reasonable trade for the provisioning flexibility and density VDS delivers. Database workloads are not most workloads.

Three mechanisms that hurt database performance on VDS

CPU steal time

Steal time is the delay a vCPU experiences waiting for the physical CPU to become available. Standard utilization metrics do not capture it, which makes it insidious: your monitoring shows 40 percent CPU usage while your query latency is spiking. Under sustained OLTP load, steal time spikes translate directly into tail latency spikes. You see them in your p99 and p99.9 numbers, not your averages.

NUMA misalignment

Modern servers are multi-socket machines with Non-Uniform Memory Access architectures. If a VM’s memory is allocated from Socket 0 but its vCPU is scheduled on Socket 1, every memory access crosses the inter-socket interconnect. That remote memory access penalty adds tens of microseconds per operation. On bare metal you pin your database process to a NUMA node and keep memory local. Inside a VM, the hypervisor’s scheduler makes that decision, and it is not always optimal for your workload.

Noisy neighbor on shared micro-architectural resources

Even a well-isolated VDS on a dedicated physical host shares L3 CPU cache and memory bandwidth with any other guests on that host. A neighboring VM running a cache-thrashing workload, such as video transcoding or a bulk analytics job, can evict your database’s hot working set from cache. The next query misses cache and goes to storage. This is not a theoretical risk; it is the mechanism behind the performance variance that makes p99 latency unpredictable on virtualized infrastructure.

P99 latency is where the bare metal advantage concentrates. Median performance on VDS often looks acceptable; the worst one percent of requests is where steal time spikes and cache eviction show up, and those are exactly the requests your users notice.

The storage path: where VDS loses ground fastest

On bare metal, your database’s Write-Ahead Log writes go directly over PCIe to a local NVMe drive. Native NVMe latency sits around 20 to 50 microseconds. On a VDS using virtio-scsi or virtio-blk, the I/O request travels through a software path before reaching the physical device. That software layer adds roughly 10 to 30 microseconds per operation. On NVMe, that can effectively double observed storage latency.

There is a second problem specific to cloud VDS: providers frequently cap per-instance IOPS to enforce fair sharing, independent of the underlying drive hardware. A plan advertised as NVMe-backed may be throttled to 10,000 IOPS at the instance level, which is lower than what a native SATA SSD delivers unthrottled. You are paying for NVMe and receiving SATA-equivalent throughput because the quota sits above the hardware.

The benchmark data is consistent with these mechanisms. CubePath’s KVM comparison shows bare metal at 28,450 transactions per second with a 95th percentile latency of 18.3ms, against KVM at 25,630 TPS with a 95th percentile of 21.5ms, a 17.5 percent latency increase at the tail. Broader PostgreSQL benchmarks comparing bare metal to equivalent virtualized instances show 30 to 40 percent higher TPS on bare metal. NVMe accessed natively versus over a virtualized path delivers 3.8 times higher MySQL TPS and 13.9 times lower p99 latency compared to SATA SSD configurations, and at queue depth 32 where databases typically operate, NVMe provides around 650,000 IOPS against a SATA ceiling of 95,000.

When VDS is the right answer anyway

Bare metal is not the default correct answer. VDS wins on provisioning speed, cost at lower utilization, and flexibility for workloads that do not saturate the hardware. A read replica that handles 200 queries per second does not need dedicated hardware. A staging environment, a reporting database, or a microservice’s embedded store almost certainly does not either. VDS makes sense when your working set fits comfortably in cache, your query mix is read-heavy and tolerant of occasional latency variance, and you need to scale horizontally rather than vertically.

The inflection point is typically when your database’s working set approaches or exceeds available cache, when you are running OLTP at high concurrency, or when a downstream SLA requires consistent sub-millisecond storage latency. At that point, the cost of VDS’s overhead is not the instance price difference; it is the engineering time spent tuning around variability that bare metal eliminates structurally.

What this means for AI and GPU-adjacent database workloads

The bare metal market is growing at a CAGR above 20 percent, and the driver is not nostalgia for physical hardware. It is AI and GPU workloads creating new latency requirements on the database tier. A GPU inference pipeline that processes a request in 15 milliseconds cannot afford a database backend with 30ms p99 latency. Feature stores, vector databases, and real-time embedding lookups sit directly in the inference critical path.

We run GPU inference and training infrastructure at DIVERSITY, and the pattern we see consistently is that teams optimise the model serving layer and then discover the database backend is the actual bottleneck. The GPU is idle, waiting on a query. Moving the database to bare metal with local NVMe, and co-locating it in the same datacenter as the inference nodes, typically cuts that wait by more than any further model optimisation would.

Making the decision: a practical framework

  • Profile your p99 and p99.9 latency first. If your tail latency is already within budget and stable, VDS is probably sufficient. If it is variable or above target, the hypervisor and storage path are likely contributors.
  • Measure steal time explicitly. On Linux guests, top and vmstat surface steal time directly. Sustained steal above 5 percent under load is a signal that the physical host is contended.
  • Check your IOPS allocation, not just the headline storage type. Ask your provider for the per-instance IOPS cap. If it is below 50,000, you are not getting NVMe performance regardless of what the spec sheet says.
  • Co-locate compute and database in the same datacenter. Network-attached storage across a datacenter fabric adds 0.5 to 2 milliseconds of round-trip latency per I/O. Local NVMe eliminates that entirely.
  • Size the working set against available RAM. If your hot data fits in memory, storage latency matters less. If it does not, bare metal with fast local NVMe is the only reliable path to consistent p99 performance.

The choice between bare metal and VDS is not about prestige or conservatism. It is about matching the hardware’s performance characteristics to what your database actually needs. For latency-sensitive workloads, the hypervisor’s overhead is real, measurable, and concentrated exactly where it hurts most: in the tail latency that determines whether your application feels fast or unreliable.