Proxmox vs VMware ESXi: Tested Performance, Features and Cost

ESXi still moves data faster. Proxmox VE does everything else for free. That is the short version after we put both hypervisors on the same hardware and ran the same guest through the same tests, three times each.

This Proxmox vs ESXi comparison is for homelab owners and small shops. VMware now sits inside Broadcom, and many of them are deciding where their VMs go next. It covers measured CPU, memory, disk and network numbers, boot times and idle overhead, then the parts that matter more in daily use: what the free ESXi license blocks, clustering and backups, hardware support and cost. Every number below was tested in October 2026 on the free ESXi 8.0 Update 3e build and Proxmox VE 9.2, both on the same Intel Core i7-6700 host.

Proxmox vs ESXi benchmark results

Each figure is the median of three back-to-back runs inside an identical Debian 13 guest (2 vCPU, 2 GiB RAM). Spread between runs stayed within about 5% on most rows. The 1M sequential write and the p99 latencies moved more, and the disk section covers that.

Read the table as a ranking of two stacks on one box, not as bare-metal disk numbers. The disk rows are where the two differ most, and they are also the rows most shaped by our test setup, which the next section explains.

How we tested

Both hypervisors ran as nested VMs on one Proxmox VE host with an Intel Core i7-6700 (Skylake, 4 cores, 8 threads). Each got the same outer VM. That meant 4 vCPU passed through as host and 8 GiB RAM with ballooning off. Disks were a 64 GiB install disk plus a 40 GiB data disk, both on one ZFS pool. The NIC was an emulated e1000e. During the benchmark and idle runs only one hypervisor was powered on at a time. Both sides ran back to back in the same evening window, Proxmox first, then ESXi.

The guest was the same Debian 13 cloud image on both. On ESXi it used a VMFS6 datastore, the PVSCSI controller, a VMXNET3 NIC and hardware version 21. On Proxmox it used LVM-thin, VirtIO SCSI single with iothread on, and a VirtIO NIC. Those are the paravirtual devices each platform recommends for a Linux guest. On Proxmox we also set the guest CPU type to host and turned ballooning off; neither is the default.

How each number was taken:

• CPU and memory: sysbench cpu and sysbench memory with 2 threads for 30 seconds each.
• Disk: fio with direct=1 and libaio on a 4 GiB file, 45 seconds per pattern after a 5 second ramp, page cache dropped before each run. 4K patterns ran at queue depth 32, 1M patterns at 8.
• Network: iperf3 for 20 seconds each way between the guest and the physical host, then 100 pings.
• Hypervisor boot: from qm start on the physical host to the web UI returning HTTP 200.
• Guest boot: from power-on to a working SSH login on a fixed DHCP lease, three cold boots per side.
• Idle overhead: CPU time of the outer VM process over 60 seconds, sampled three times after a 10 minute settle. Memory came from vsish /memory/comprehensive (non-kernel) on ESXi and free -m on Proxmox.

Two caveats. Nesting adds a layer of emulation under both hypervisors. Absolute numbers sit below what the same box gives on bare metal. Reads can also be served from the ZFS cache on the outer host, which is how a virtual SATA disk reached 3 GB/s. Both sides sat on the same pool, but we did not measure how much each stack gained from that cache, so treat the disk gaps as specific to this setup.

CPU and memory are a tie

sysbench CPU landed within 1% across all six runs. That is expected. Both hypervisors hand the guest the host CPU through hardware virtualization, and neither gets in the way of pure compute. Memory bandwidth favoured ESXi by 5%, which is too small to change any decision.

Disk I/O: ESXi wins throughput

This is the one area where ESXi pulled clearly ahead. VMFS plus PVSCSI moved 2.2x the sequential read throughput of LVM-thin plus VirtIO SCSI, and 38% more 4K random writes. The sequential write row was the noisiest in the whole run (Proxmox 96 to 139 MiB/s across three runs, ESXi 175 to 210), but ESXi led on every single run.

Proxmox had one clean answer: lower worst-case latency on random reads. Its 4K read p99 was 5.08 ms against 6.06 ms on ESXi, and its slowest run still beat the best ESXi run. The random write p99 looks better on Proxmox too, but one of its three runs reached 8.03 ms, so treat that row as a tie. Both latency results came at 10 to 27% fewer IOPS, so they aren’t a free win.

Storage choice also moves these numbers more than the hypervisor does. We used LVM-thin because it is the closest match to a VMFS datastore on a single disk. Proxmox can also put VM disks on ZFS, Ceph, directories or NFS. Each behaves differently. The Proxmox storage types comparison covers which to pick.

Network, ping and boot times

VMXNET3 on ESXi pushed 24% more traffic out of the guest and 43% more in. Both sides sat behind the same emulated e1000e NIC on the outer VM, so the absolute numbers reflect that layer, and host-to-guest traffic stayed well below guest-to-host on both. Proxmox had the lower ping, 0.54 ms against 0.67 ms.

Proxmox booted from power-on to a working web UI in 24.4 seconds. ESXi took 47.9 seconds, and a cold boot two days earlier took 46.9, so that gap is repeatable. Guests went the other way: a Debian guest reached SSH 4.7 seconds sooner on ESXi. Inside the guest, kernel plus userspace took 12 to 14 seconds on both platforms, and systemd-analyze differed by under 1 second. Most of the gap sits outside the guest OS.

This catches people out when scripting ESXi. In one early run, our script waited for VMware Tools to report the guest IP before trying SSH, and it measured 50 seconds. Polling SSH directly on the known address gave 23 seconds. If an automation waits on the Tools IP, time it before trusting it.

Idle overhead

With no guest running, the ESXi VM burned 9% of one host core doing nothing. Proxmox used 4%. With one idle guest on each, that became 14.8% against 6.1%. On a single small box it is noise. On a nested lab or a laptop it shows up as fan noise and heat.

Memory in use after boot was close: 1,511 MiB non-kernel memory on ESXi and 1,464 MiB used on Proxmox. These are different counters on different kernels, so treat them as “about the same”, not as a winner. The bigger difference was outside the guest. From the physical host, the ESXi VM process held 8,221 MiB (its full 8 GiB plus QEMU overhead), while the Proxmox VM held 2,386 MiB. ESXi had touched every page it was given by the time it settled. If you nest ESXi on a Proxmox host, count its full RAM allocation as used. For sizing a Proxmox host itself, the Proxmox homelab RAM guide has measured numbers per workload.

What the free ESXi license allows

Broadcom brought back a free ESXi in 2025 as the 8.0 Update 3e build, with the license key embedded in the ISO. No key entry is needed. The installed license reports itself like this:

vim-cmd vimsvc/license --show | grep -E "vmodl key|name:|unit:|feature"

The vsmp:8 feature is the 8 vCPU per VM cap:

   vmodl key: esx.hypervisor.cpuPackageCoreLimited
   name: vSphere 8 Hypervisor
   unit: cpuPackage:32core
     [feature] = vsmp:8 ("Up to 8-way virtual SMP")

According to Broadcom KB 399823, the free license allows up to two physical CPUs per host and 8 vCPUs per VM, with management through the Host Client only. It cannot join vCenter. That rules out vMotion, HA and DRS. There is no VADP, which means Veeam and other image-level backup tools cannot back up its VMs. The API is read-only. There is no Broadcom support.

The Host Client below is the whole management surface. vMotion shows “Not supported” and the host is not connected to any vCenter Server:

The Broadcom KB for the free hypervisor covers only that ESXi 8 build. ESX 9 ships as part of the VMware Cloud Foundation and vSphere Foundation subscriptions. A homelab on free ESXi is therefore pinned to version 8 for as long as Broadcom keeps patching it. Our ESXi 8 bare-metal install guide walks through the installer if you still want to run it.

Hardware support: the CPU warning

ESXi checks the CPU at install time. On our Skylake i7-6700 the installer stopped with this warning before it would continue:

The warning is not idle. Broadcom KB 318697 lists Skylake-S (CPUID 0x506E3, the same family as the Xeon E3-1200 v5) as discontinued in ESX 9. Plenty of homelab boxes are built on used parts from exactly that generation. Proxmox VE installed on the same CPU with no warning, because it runs a standard Linux kernel and its driver set. The same goes for consumer NICs and storage controllers that are not on the VMware compatibility list, which is why Proxmox is the usual pick for the mini PCs people buy for homelabs.

What Proxmox VE gives you without a license

Every Proxmox VE feature works with no subscription. The subscription only buys support and access to the enterprise repository. The node summary flags the missing subscription and nothing else:

Switch to the free repository after install so updates work. The steps are in our Proxmox no-subscription repo guide. The version string on the test node:

pveversion

It reports the manager release and the running kernel:

pve-manager/9.2.2/b9984c6d90a4bd80 (running kernel: 7.0.2-6-pve)

Against the free ESXi, the differences that change how you run a lab are these:

LXC containers are the feature ESXi users miss most once they have them. They start in seconds and share the host kernel, and the Debian and Ubuntu LXC guide shows the setup. VM hardware is also plain to read and edit. Our bench guest in the hardware tab, with VirtIO SCSI single and iothread on its disk:

Recent releases added a dynamic load balancer for clusters, and the Proxmox VE 9 release overview lists the changes.

Cost: Proxmox subscription vs VMware licensing

Proxmox VE costs nothing to run. Paid plans are priced per occupied CPU socket per year, and every plan includes the same features. They differ in support terms:

Prices are from the Proxmox VE pricing page. On the VMware side, the free ESXi costs nothing but stops at one host with no backups API. Anything beyond that, including vCenter, clustering and ESX 9 itself, comes through VCF or VVF subscriptions from Broadcom. Those are licensed per physical core with a 16-core minimum per CPU, per Broadcom KB 313548, so even a 4-core homelab CPU is billed as 16, and resellers often quote a larger minimum per order. The other legal route to ESX 9 at home is a VMUG Advantage personal-use license, which needs a paid membership plus a passed VCP-VCF exam. For a two-node homelab cluster with HA, Proxmox is the only one of the two that does it at zero cost.

Which one to run

Run Proxmox VE if you want more than one host, any form of backup, containers, or a CPU that ESX 9 has dropped. That covers most homelabs. Its lower random-read tail latency and half-the-idle-CPU result are a bonus.

Keep free ESXi if you run one host, need VMware skills for work, and your workload is sequential disk throughput. That is where it measured 2.2x faster here. Accept that you are on the version 8 line with no vendor support and no image-level backups.

Moving a homelab off ESXi: what changes

Proxmox VE has an import wizard that reads VMs straight from an ESXi host, and the ESXi to Proxmox migration guide covers it step by step. Install Proxmox first on separate hardware or a spare disk, using the Proxmox VE 9 install guide.

The virtual hardware is what changes under the guests. VMXNET3 becomes VirtIO net, PVSCSI becomes VirtIO SCSI, and VMware Tools gets replaced with qemu-guest-agent. Linux guests already carry VirtIO drivers in the kernel, so they boot after the switch. Windows guests don’t. Load the VirtIO drivers before you move them, or boot them on SATA first and add the drivers later. The VirtIO drivers for Windows guide shows both paths.

Interface names inside Linux guests often change with the new NIC model. A static IP bound to ens192 then comes up unconfigured. Check the guest console after the first boot before you decommission the ESXi host. Once the VMs run, set up a backup job in Datacenter, Backup. That is the feature the free ESXi never had.