Optimization

Bare Metal for Database Workloads: NVMe, IOPS and Noisy Neighbours

BM BizMaC Team Jun 22, 2026 10 min read

The first thing you notice when running a write-heavy database inside a virtualised environment is the I/O jitter. One moment your transaction log writes complete in under a millisecond; the next, a neighbouring VM kicks off a backup job and your commit latency triples. If you have managed PostgreSQL, MariaDB, or MySQL instances on shared virtualisation platforms, you have felt this. The question is not whether virtualisation imposes overhead, it does, but whether the cost matters enough for your specific workload to justify moving to bare metal. For many database-intensive applications, the answer is a clear yes.

写入密集的数据库对NVMe和IOPS敏感，虚拟化层会带来损耗。

Write-heavy databases are sensitive to NVMe and IOPS, and a virtualization layer costs you some of both.

Why Virtualisation Introduces Noise for Database I/O

Every VPS runs on a hypervisor, KVM, Xen, VMware, or Hyper-V, that multiplexes physical hardware across multiple tenants. CPU and memory overhead are well-documented and generally predictable. Storage I/O, however, behaves differently because the hypervisor intercepts every disk operation through at least two layers: the guest's storage driver (virtio, IDE, or SCSI emulation) and the host's storage stack (the host filesystem, volume manager, and physical driver). Each layer adds latency variance.

The real problem is not average latency, it is the tail latency distribution. Under light load, a KVM guest on an NVMe drive can deliver 50-80µs reads, close to bare metal. Under contention, when the host's IO scheduler merges requests from multiple guests or the storage controller handles competing queues, the p99 latency can jump to 5-10 ms. For a database that writes a transaction log synchronously, that variance creates back-pressure: the database stalls waiting for fsync() to return. This is the noisy neighbour effect, and it is the strongest argument for bare metal for database workloads.

What Bare Metal Eliminates, and What It Does Not

A bare metal server gives you the entire NVMe device, the entire PCIe bus to that device, and full control over the I/O queue depth and scheduler. There is no intermediate hypervisor layer. The database talks directly to the NVMe controller, which exposes multiple hardware queues upstream of the CPU cores. On a modern NVMe drive, a single queue pair can sustain over 500,000 IOPS (4 KB random writes) with sub-100µs p99 latency, figures that a shared-host virtual machine essentially never achieves under real multi-tenant load.

However, bare metal is not immune to noise. If you colocate two database instances on the same server and one runs an aggressive checkpoint or a heavy ANALYZE, the other still contends for the same NVMe queue. The difference is that you control the contention rather than having a hypervisor inject it unpredictably. On a dedicated server, you can partition the NVMe namespace, pin CPU cores, and tune the deadline or mq-deadline I/O scheduler per namespace. A VPS tenant cannot do any of that.

When Virtualisation Is Fine, and When It Breaks

Not every database workload needs bare metal. Read-heavy web applications on a well-tuned MariaDB instance with a large InnoDB buffer pool and a fast NVMe-backed VPS are perfectly happy. If the working set fits in memory and writes are mostly log-buffered, the hypervisor overhead is negligible. The breaking point is write throughput with synchronous durability, that is, workloads that call fsync() after every transaction commit. These include OLTP applications, financial systems, queuing backends, and any database that must guarantee ACID compliance across restarts.

A single percona-server instance in a 4-CPU / 8 GB KVM guest on NVMe storage can push about 2,500-3,500 write IOPS before the hypervisor begins introducing visible latency. The same workload on a bare metal server with the same NVMe drive often sustains 15,000-20,000 write IOPS with stable sub-millisecond latency. The multiplier is not small. For a senior DBA, this gap is the difference between a system that requires constant tuning to stay within a latency budget and one that simply delivers.

NVMe on Dedicated Hardware: Real-World IOPS and Throughput

The term NVMe is thrown around loosely in hosting marketing. In practice, NVMe delivers 4-6× the IOPS of SATA SSD with one-tenth the latency, but only if the host CPU, the PCIe generation, and the drive firmware are matched. A dedicated server running an NVMe Gen4 drive behind an eight-lane PCIe slot can deliver up to 1 million random read IOPS and approximately 6-7 GB/s sequential throughput. Sustained random write IOPS on TLC or QLC NAND depends on the drive's SLC cache. After the cache fills, sustained write speeds can drop to 80-150 MB/s per drive, so a write-heavy database should use a drive with a large SLC buffer and high TBW rating, or a datacenter NVMe like the Samsung PM9A3 or Kioxia CD8P.

For comparison, an NVMe VPS on a shared host typically sees 30-50% of the raw device performance, not because the drive is slow, but because the hypervisor and competing tenants consume queue slots. A VPS plan on a single-NVMe node with 10 or 15 tenants will show 30-70µs read latency during quiet periods and 500µs-3ms during busy periods. On bare metal, the latency stays flat regardless of what else runs inside the server, because you control what runs.

When to Choose Bare Metal for Database Workloads

The decision matrix has three dimensions:

  • Write IOPS requirement: above 5,000 sustained synchronous writes per second → bare metal. Below 2,000 → a well-provisioned VPS works.
  • Latency sensitivity: if p99 write latency above 1 ms causes application timeouts or queue backlogs → bare metal.
  • Consistency of load: if the database shares the host with other unpredictable workloads (backups, ETL, batch processing) → bare metal gives you the ability to isolate them with cgroups and I/O scheduling.

Conversely, if your database serves a small-to-mid-sized application, you use caching (Redis, Memcached) effectively, and you are on a host with a well-designed storage architecture, separate NVMe pools, no overselling of IOPS, a VPS remains cost-effective and operationally simpler.

Why Placement in Vietnam Matters for Local Traffic

If your users, partners, or internal systems are inside Vietnam, the physical location of the hardware matters more than whether it is virtual or dedicated. A database server placed in a Vietnamese datacenter, such as those operated by Viettel IDC (a subsidiary of Viettel Group, the state-owned military telecom) or VNPT IDC (the datacenter arm of the state-owned telecom VNPT), terminates domestic traffic without crossing international transit. Every time a database query leaves Vietnam to reach a server in Singapore or Hong Kong, it incurs an extra 30-60 ms of latency, or more during peak hours, because the route must traverse submarine cables and international peering exchanges.

For applications serving Vietnamese users, a Vietnam-based bare metal server or VPS provides lower and more consistent latency because the traffic stays on domestic backbones owned by Viettel, VNPT, FPT Telecom, and CMC Telecom, the four incumbent providers that operate the country's internet infrastructure. The routing is shorter and the domestic bandwidth is significantly cheaper than international transit, which means the provider can offer generous bandwidth allocations without throttling. This is particularly relevant for database mirroring, replication streams, and any sync-heavy workload where latency directly affects throughput.

However, and this must be stated clearly, a Vietnam-based server is not a shortcut for reaching other countries. Any traffic leaving Vietnam travels through one of the submarine cables landing in Da Nang or Vung Tau (AAE-1, AAG, APG, SMW5, or ADC) and then depends on the reader's own domestic network on the other end. A Vietnam server serves Vietnamese traffic best. It is local infrastructure for local work.

Bare Metal Server Options in Vietnam

For workloads that outgrow VPS, dedicated servers with NVMe storage are available in the same Vietnamese datacenters. A typical configuration, an Intel E5-2670 v3 or newer Xeon with 64 GB ECC RAM and a 2 TB NVMe drive, can run a dozen database instances before I/O becomes a concern, provided the storage subsystem is architected correctly. These servers ship with unlimited bandwidth, a dedicated IPv4 address, free rDNS for email reverse-lookup setup, and an IPKMI (remote KVM) that gives you full console access even when the OS is down.

For companies that want a dedicated server for database hosting in Vietnam, the hardware can be customised: additional NVMe drives in a RAID-free JBOD configuration (preferred for database hot-spares), bonded NICs, and specific BIOS power profiles. Colocation is also available at the same Tier 3 facilities, Viettel IDC or VNPT IDC, for organisations that already own the hardware but need Vietnamese physical presence. A standard colocation commit is 100 Mbps on a 1 Gbps port with 400W per 1U.

If you are evaluating whether bare metal makes sense for your database, consider renting a dedicated server in Vietnam with NVMe storage and a clean IPv4 address. A single server dedicated entirely to your database eliminates the variable that most degrades write-heavy workloads: the unpredictability of a shared hypervisor.

FAQ

Does a VPS ever outperform a dedicated server for databases?

Rarely, and only when the hypervisor uses dedicated NVMe passthrough (PCIe passthrough of the entire NVMe controller to a single guest) and the host is not oversubscribed. In that specific configuration, the performance gap narrows to under 5%, but this is not available in standard multi-tenant VPS plans. For normal shared-infrastructure VPS, the gap remains significant.

How much more expensive is bare metal compared to a VPS?

In the Vietnam market, a dedicated server with comparable CPU and RAM costs roughly 4-6× monthly billing of an equivalent VPS. The price difference narrows when you factor in the dedicated bandwidth, the free IPKVM, and the elimination of noisy neighbour mitigation work. For a write-heavy database that must stay under a latency budget, the operational savings often justify the higher hardware cost.

Can I use a VPS with NVMe storage and avoid noisy neighbour issues?

Partially. Choose a provider that does not oversubscribe NVMe IOPS and that uses dedicated NVMe pools per host rather than shared SAN or distributed storage. Also pick a plan with enough resources to handle the database working set plus headroom. But you cannot completely eliminate the hypervisor overhead. If your workload's p99 latency budget is under 500µs, bare metal is the safer choice.

What is the typical write IOPS a bare metal NVMe database server delivers?

For synchronous random writes (crash-safe) with a single queue depth, a decent Gen4 NVMe datacenter drive delivers between 80,000 and 150,000 4 KB write IOPS, depending on the SLC cache size and the flash type (TLC vs MLC vs SLC). For real-world OLTP workloads with concurrency, you typically see 20,000-40,000 sustained write IOPS before the drive's garbage collection kicks in.

Do I need special kernel tuning for bare metal NVMe databases?

Yes. The two most impactful knobs are the I/O scheduler, set to mq-deadline or none (none is often best for NVMe because NVMe manages its own queue prioritisation), and the block device's queue depth via queue/depth sysfs. Also set the database's direct I/O flag (e.g., innodb_flush_method=O_DIRECT in MariaDB/MySQL or full_page_writes=on in PostgreSQL) to bypass the OS page cache and reduce double-buffering.

Is colocation a good option for a database server?

It depends on the volume. Colocation makes sense when you already own the hardware, you need a Vietnam-specific IP range, and you prefer to pay a monthly rack fee rather than renting the whole server. The infrastructure at Viettel IDC or VNPT IDC includes redundant power (UPS and backup generators), cooling, and physical access. For a single database server, renting a dedicated server is usually simpler and cheaper than colocation.

Related articles

Note: This guide is for general reference. Every system and infrastructure has its own specifics, so test each step in a safe environment and consult a qualified engineer before applying it in production.

数据库负载与裸金属的NVMe性能

写入密集的数据库对NVMe和IOPS非常敏感，虚拟化层会带来可观的损耗。文中说明如何测量真实IOPS并判断是否需要裸金属。测量结果比参数表更有说服力。