VPS vs Bare Metal for Database Workloads: Real Benchmarks for MySQL, PostgreSQL, and MongoDB

Database performance is the most workload-dependent variable in infrastructure decisions. A VPS might handle web serving beautifully but choke on OLTP database workloads that a bare metal server eats for breakfast — or vice versa. We ran real benchmarks on MySQL, PostgreSQL, and MongoDB across both VPS and bare metal environments to settle the question with data, not opinions.

Why Virtualization Affects Databases Differently

Web servers are mostly CPU-bound and cache-friendly, which is why hypervisor overhead barely shows up in web benchmarks. Databases are different: they depend on low-latency disk writes (fsync), consistent CPU availability, and predictable I/O scheduling. Every layer of virtualization — the hypervisor’s I/O queue, the shared disk subsystem, CPU steal time from noisy neighbors — adds variance, and databases are the workloads most sensitive to that variance.

Three virtualization effects matter most for database workloads:

fsync latency: every committed transaction waits for a disk flush. On a VPS, that flush travels through the hypervisor’s I/O stack, adding 2–5 ms per commit on shared storage.
CPU steal: when the hypervisor schedules other tenants on your vCPUs, your database threads stall. Steal above 3% visibly degrades transaction latency.
I/O variance: shared NVMe bandwidth means neighbor workloads create latency spikes that wreck p99 commit times.

Test Methodology

VPS configuration: 4 vCPU, 16 GB RAM, 160 GB NVMe (KVM, dedicated host)
Bare metal configuration: AMD EPYC 7282 (8 cores), 32 GB RAM, 2× NVMe RAID-0
Benchmark tools: sysbench (MySQL/PostgreSQL), mongodb-perf (MongoDB)
Each test: Run 5 times, median reported. Tables scaled to 10M rows.

MySQL 8.0 Results

Workload	VPS (4 vCPU / 16 GB)	Bare Metal (8C / 32 GB)	VPS % of Bare Metal
OLTP Read/Write (TPS)	4,820	8,150	59%
Read-Only (QPS)	38,400	52,100	73%
Write-Only (QPS)	12,100	24,300	49%
Point Select (latency, ms)	0.31	0.19	—
Range Select (latency, ms)	2.1	1.3	—

Key takeaway: Write-heavy MySQL workloads see the biggest gap. The hypervisor introduces latency for fsync operations, which directly impacts write throughput. The read-only gap (73%) is much smaller than the write-only gap (49%) — reads are served from the buffer pool and never touch the I/O stack. If your app does more than 70% writes, bare metal is worth the premium.

PostgreSQL 16 Results

Workload	VPS (4 vCPU / 16 GB)	Bare Metal (8C / 32 GB)	VPS % of Bare Metal
OLTP Read/Write (TPS)	3,950	7,210	54%
Read-Only (QPS)	31,200	46,800	66%
Write-Only (QPS)	9,800	21,500	45%
Vacuum (duration)	14.2s	7.8s	—
Checkpoint (duration)	3.1s	1.4s	—

Key takeaway: PostgreSQL’s MVCC and checkpoint behavior amplifies the VPS disadvantage. Vacuum and checkpoint operations rely heavily on sequential I/O, and the hypervisor’s I/O scheduling adds latency variance. For analytical workloads with large sequential scans, bare metal is 1.5–2× faster. The 45% write-only gap is the worst result in this entire benchmark set.

MongoDB 7.0 Results

Workload	VPS (4 vCPU / 16 GB)	Bare Metal (8C / 32 GB)	VPS % of Bare Metal
Read Ops/sec	29,400	38,200	77%
Write Ops/sec	14,200	25,100	56%
Update Ops/sec	11,800	21,400	55%
Index Scan (latency, ms)	0.42	0.28	—
Aggregation (latency, ms)	4.7	2.9	—

Key takeaway: MongoDB’s in-memory engine and document model narrow the gap for read operations — the VPS achieves 77% of bare metal read throughput, the best relative result of all three databases. However, write operations with journaling enabled still incur the fsync penalty, widening the gap to ~55%.

When to Choose VPS vs. Bare Metal for Databases

Workload Profile	Recommendation	Rationale
Read-heavy web app (>80% reads)	VPS (high-RAM plan)	Cache absorbs read latency; hypervisor overhead minimal
Write-heavy OLTP	Bare metal	fsync latency on VPS cuts write throughput ~50%
Analytics / data warehousing	Bare metal	Sequential scan throughput is 1.5–2× on bare metal
Development / staging DB	VPS	Cost savings of 60–70% over bare metal
MongoDB read-heavy	VPS	Only 23% gap vs bare metal — VPS value wins
MongoDB write-heavy	Bare metal or high-end VPS	Journaling fsync penalty still significant

Optimizing a VPS for Database Workloads

If you’re committed to a VPS but need better database performance, these five adjustments close most of the gap:

Size the buffer pool correctly — MySQL’s innodb_buffer_pool_size and PostgreSQL’s shared_buffers should be 50–70% of available RAM. On a 16 GB VPS that means 8–11 GB, not the default 128 MB.
Use NVMe-backed plans — storage I/O is the bottleneck; NVMe drops latency by 10× vs SATA SSD and reduces the fsync penalty substantially.
Pin CPUs if your provider offers it — CPU pinning reduces steal time variance by locking your vCPUs to physical cores.
Monitor steal time — check /proc/stat or vmstat for steal columns; sustained >3% means the host is oversubscribed and you should switch providers.
Use connection pooling — PgBouncer or ProxySQL reduces per-connection overhead that’s amplified under virtualization, especially at high concurrency.

One configuration detail worth testing: tune innodb_flush_log_at_trx_commit (MySQL) or synchronous_commit (PostgreSQL) to off for non-critical workloads. You trade durability for a 3–5× write improvement, which is acceptable for staging or analytics replicas but not for transactional production data.

The Bottom Line

VPS vs bare metal for databases is not a binary question — it depends on your read/write ratio and latency requirements. Read-heavy workloads run fine on a well-configured VPS at a fraction of bare metal cost. Write-heavy OLTP and analytics workloads pay a 45–55% throughput penalty on virtualized hardware, and bare metal earns its premium there.

Choosing the right VPS provider for database workloads starts with understanding their virtualization stack and storage infrastructure. See our VPS provider comparison table for real-world database benchmarks across providers to find the best fit for your workload.