The best container runtime for a Mac, benchmarked.

Test bench

Method

Start and pull

Apple's runtime is ready fastest and starts each container slowest, because each one is a VM. Its image pulls are six times slower than the others for the same four images.

Compute

Under seven per cent spread on every compute metric. All five sit on the same hypervisor and the same silicon; work that stays inside the container does not see the runtime.

The host filesystem boundary

The same untar, checksum and delete cycle on a host bind mount, where a mounted source tree lives, and on a native volume, which never leaves the VM. Bind-mount times differ four times across runtimes; volume times differ two, and the order inverts. The lines below are near-parallel, so the gap is a constant factor, not a scaling difference.

Build

Cold builds differ by a factor of two. Rebuilding after a one-line source change differs by nearly twelve, and that is the operation paid dozens of times a day.

Network

One stream flatters the published-port path; sixteen at once show it under load. Docker Desktop moves 2,057 MiB/s on one stream and 152 across sixteen. Apple's container-to-container figure is low because that traffic crosses a virtual network between two VMs rather than staying inside one kernel.

Under heavy load

pgbench at scale 150 (2.2 GB) with 32 clients for two minutes; five minutes of simultaneous CPU, small-file and block-I/O contention; three containers each holding a 4 GiB working set against an 8 GB ceiling; up to fifty containers at once. OrbStack is three to four times faster on the host filesystem and posts half Docker Desktop's database throughput, which matches its random-write figure on volumes. A source tree and a database sit on opposite sides of the same trade.

Airflow and InfluxDB, arm64 and amd64

Airflow 3.3.1 running a three-task pipeline that moves eight million rows through SQLite. InfluxDB 2.9.1 under four concurrent writers pushing ten million points, then four full-range Flux queries. Both repeated with the whole stack emulated onlinux/amd64, at 2M rows and 1M points, compared as rates. Natively the runtime barely matters; emulated, it decides everything.

The Rosetta flag

On a synthetic CPU test Colima's emulation penalty was 63.82x against 5.4 to 10.3 for the others. Rosetta is off by default in Colima and is requested when the VM is created. Rebuilt with --vz-rosetta the penalty fell to5.22x, the lowest of any runtime. A creation-time flag is one most teams will not pass. Native beats emulated by enough everywhere that building arm64 images for local work is worth doing whatever production runs on.

Disk

Measured with each runtime stopped, so shutdown compaction is counted. Three of five return space when images are deleted. Apple stores images as expanded per-image filesystems, so its loaded footprint is large, and all of it comes back. Colima's purge left ten images behind, so its figures are an upper bound.

Compatibility

Ten features a typical project depends on. The gaps stop work rather than slow it: no Engine API means socket-driven tooling cannot see the runtime; no Compose means the stack file does not run; no socket mount means Testcontainers does not run. Podman's Compose failure is one service, RabbitMQ, which took the stack down with it. Started by hand with plain run commands, every runtime brought the same four services up in 2.5 to 5.1 s.

Hypotheses

Written before the data existed; scored against it afterwards.

What went wrong

Each of these produced a clean, plausible, wrong number, and none announced itself. They were caught by re-checking the surprising results by hand. The full list of seventeen deviations is in the protocol file next to the raw data; these are the ones that changed a result.