Docker VMM vs WSL2/Hyper-V: Docker Desktop Performance Guide (2026)

Docker VMM vs WSL2/Hyper‑V: Docker Desktop Performance Guide (2026)

If your Docker Desktop feels sluggish on Windows, the backend you choose (Docker VMM, WSL2, or Hyper‑V) and how you configure it often matter more than your hardware. This guide explains what each backend is, how they differ in performance, and how to tune them with concrete examples so you can stop waiting on containers and start shipping.

What Each Backend Actually Is

• Docker VMM – Docker’s own first‑party virtual machine manager, now in public beta (v4.86+). It still runs containers in an isolated VM but is optimized for faster startup, better file I/O, and improved idle memory reclamation on both Mac and Windows.

• WSL2 backend – Docker Desktop runs the Linux engine inside a WSL2 distro. It uses a lightweight utility VM, integrates tightly with your Linux filesystem, and dynamically shares memory with Windows.

• Hyper‑V backend – The older “MobyLinuxVM” approach where Docker runs in a dedicated Hyper‑V VM. It’s more rigid in resource allocation and generally slower for typical dev workflows, especially with bind mounts from Windows.

In practice, WSL2 has been the recommended default for most Windows developers since 2024–2025, and Docker VMM is positioned as the next‑gen option that aims to combine Hyper‑V‑style isolation with WSL2‑like speed.

Performance Differences That You’ll Actually Feel

Benchmarks and real‑world tests consistently show WSL2 outperforming Hyper‑V for day‑to‑day development:

• Startup speed: WSL2 typically starts in seconds; Hyper‑V takes longer to boot the MobyLinuxVM.

• File I/O and bind mounts: Mounting Windows paths (/mnt/c) in WSL2 is already faster than Hyper‑V, but the real win comes from mounting from the WSL2 native filesystem (/home/you), which can be ~3× faster for operations like npm install and git status.

• CPU and memory behavior: WSL2 dynamically releases unused memory back to Windows, while Hyper‑V allocates a fixed chunk up front, which can starve the host or waste RAM.

• Representative benchmark (i7‑11800H, NVMe): WSL2 shows better sequential and random disk performance, lower network latency, and faster container start times than Hyper‑V.

Early reports on Docker VMM indicate faster container startup and quicker file I/O compared to previous engines, with idle memory reclamation improvements, though it’s still in beta as of late 2026.

When to Use Which Backend

• Use WSL2 if: You’re on Windows 10/11 (Home or Pro), doing typical web/backend dev with bind mounts, and want the best balance of speed, compatibility, and tooling support.

• Consider Docker VMM if: You want stronger isolation like Hyper‑V but with WSL2‑class performance, and you’re comfortable running beta software. This is especially interesting for teams standardizing on Docker Desktop across Mac and Windows.

• Stick with Hyper‑V only if: You have legacy constraints, specific enterprise policies, or older setups that can’t use WSL2. For most new projects, it’s no longer the best default.

Example 1: Measuring the Impact of Backend and Mount Path

Suppose you have a Node.js API with many small files. You can feel the difference with a simple test.

Step 1 – Prepare two project copies:

# In WSL2 (Ubuntu)
mkdir -p ~/projects/api-wsl ~/projects/api-win
cp -r /mnt/c/Users/you/projects/api ~/projects/api-wsl
cp -r /mnt/c/Users/you/projects/api ~/projects/api-win

Step 2 – Run npm install via Docker with different mounts.

From WSL2, in ~/projects/api-wsl:

docker run --rm -v "$PWD":/app -w /app node:20 npm install

From the same shell, but mounting the Windows path:

docker run --rm -v /mnt/c/Users/you/projects/api:/app -w /app node:20 npm install

Typical results on modern hardware:

• WSL2 native path ($PWD in /home/you): ~8–12s

• Windows path via /mnt/c: ~80–100s

This matches published data showing npm install on WSL2 native filesystem around 8.2s vs 94.3s on /mnt/c. The backend choice (WSL2 vs Hyper‑V) further widens or narrows this gap, with WSL2 generally faster.

Example 2: Tuning WSL2 for Heavy Docker Workloads

If you run multiple stacks (databases, queues, apps), unconstrained WSL2 can eat RAM and make Windows sluggish. A .wslconfig file gives you predictable behavior.

Create %USERPROFILE%\.wslconfig:

[wsl2]
memory=8GB
processors=4
swap=4GB
localhostForwarding=true

Then apply:

wsl --shutdown
# Restart Docker Desktop

This caps WSL2 at 8 GB and 4 vCPUs, preventing it from starving the host while still giving Docker plenty of headroom.

For very heavy projects, guides suggest allocating ~50% of CPU and ≥12 GB RAM, plus storing code in the WSL filesystem and pruning regularly.

Example 3: Switching to Docker VMM (Beta) and Comparing

If you’re on Docker Desktop v4.86+ and want to try Docker VMM:

1. Open Docker Desktop → Settings → General.

2. Under Virtual Machine Manager, select Docker VMM.

3. Click Apply & Restart.

To see if it helps your workload:

• Time container startup:

  bash — session

  time docker run --rm alpine echo hello

• Time a typical build:

  bash — session

  time docker build -t myapp:test .

• Measure file‑heavy operations inside a container with bind mounts from your WSL home directory.

Compare these timings before and after switching from WSL2 to Docker VMM. Early documentation emphasizes faster startup and improved file I/O, but your mileage will depend on workload and hardware.

Practical Optimization Checklist (WSL2 or VMM)

Apply these regardless of backend to eliminate common sources of “Docker is slow”:

• Enable WSL2 backend (or Docker VMM if you’re testing it) and keep WSL updated.

• Store code in WSL’s native filesystem (/home/you/projects), not on /mnt/c.

• Use .wslconfig to cap memory and CPUs for predictable performance.

• Prefer named volumes for databases and high‑churn data instead of bind mounts to Windows paths.

• Prune regularly:

  bash — session

  docker system prune -a
  docker volume prune

  This reclaims disk and speeds up metadata operations.

• Use BuildKit and optimize Dockerfiles (multi‑stage builds, cache‑friendly layer ordering, tight .dockerignore).

• Run Docker CLI from WSL, not PowerShell, to avoid cross‑filesystem confusion and extra path translation.

Recommendation for Most Developers in 2026

For typical DevOps, backend, and full‑stack workloads on Windows:

• Default: Use Docker Desktop with WSL2 backend, code in the WSL filesystem, and apply .wslconfig tuning. This setup consistently delivers the best real‑world performance and tooling integration.

• Advanced / experimental: Try Docker VMM if you want next‑gen performance and stronger isolation, and you’re comfortable with beta software. Measure your own workloads before standardizing.

• Avoid as default: The classic Hyper‑V backend unless you have a specific requirement. It’s generally slower for dev workflows, especially with heavy file I/O and bind mounts.