Docker's alpine cold start swings fourfold between two 2026 benchmark writeups

Compare the absolute cold-start numbers before the percentages. Leaper.dev clocked Docker at 0.31 seconds starting an alpine container ^[11]. Tech-insider clocked Docker at 1.23 seconds on alpine 3.20 ^[16]. Same engine, same kind of image, about four times the time ^[1]. Podman moves the same way between the two writeups, 0.28 against 0.81, a factor of 2.9 ^[2]. Leaper's setup is the one specified down to the machine: Docker Engine 27.x against Podman 5.4 on a Ryzen 9 7950X, ten runs per test, medians reported ^[10]. The dev.to author's explanation for the disagreement across the four writeups he compared is that they tested different modes on different hardware ^[20].

Berton's figures support that reading of it. Rootful cold start is about 0.30 seconds for Docker and 0.35 for Podman across 100 sequential starts ^[5]. Rootless is 0.42 and 0.45 ^[6]. Berton describes rootless as adding roughly 25 to 30 percent ^[6]; the Docker pair works out to 40 percent and the Podman pair to 29 ^[3][4]. Inside a mode, the engines sit 0.03 to 0.05 seconds apart. Switching mode costs 0.10 to 0.12 seconds ^[9].

Networking is where one default outweighs everything else in these tables. Rootful bridge networking reaches about 40 Gbps, rootless on slirp4netns about 3, rootless on pasta about 15 ^[7]. That is 13x between rootful and slirp4netns, and 5x between pasta and slirp4netns ^[5][6]. pasta is Podman's rootless default from 4.0 on, and Docker's rootless mode still defaults to slirp4netns ^[9].

For a number here to transfer, you have to be running the mode that produced it, and for the I/O figure you also have to be writing where the test wrote. Rootless swaps kernel overlay2 for fuse-overlayfs and a 1 GB sequential write drops from roughly 800 to 600 MB/s; a volume mount bypasses the overlay and erases the gap ^[8]. Under steady load the two converge: nginx served 89,200 requests per second on Docker and 84,500 on Podman, about 5 percent apart ^[15][10], because both engines use the same kernel namespaces and cgroups ^[21].

Idle, Podman uses 0 MB and Docker's daemon holds 140 to 180 MB ^[17]. Tech-insider's fleet figure of roughly 14 GB reclaimed across 100 nodes ^[18] is that daemon at the low end of its range, 140 MB times 100 ^[7]. The 30-container difference the same writeup reports, 2.55 GB against 3.0 GB, is another 45 GB across those nodes ^[18][8]. Docker takes the API test, 21 ms against 32 to list 100 containers, because a warm daemon has the metadata cached and a fork-exec model collects it fresh ^[19].

None of that decides the daemon question. Docker's CLI talks to dockerd, a long-running process that owns every container on the host, and container management stops when it stops ^[1]. Anything that can write to /var/run/docker.sock has root on the host in practice, because the daemon will mount any path you ask into a container ^[2]. Podman forks each container from the command, so containers are children of your shell session or a systemd unit ^[3]. Benchmark tables do not have a column for that. On a host where a CI agent builds images, I take the daemonless default, because the alternative is handing that agent a socket with root's reach. On a workstation where I list containers all day, the 21 ms argues for the daemon. Either way the images and the compose file survive the choice: a Compose file written for Docker runs under Podman's compose command ^[4].