Container Runtime Comparison: Docker vs containerd vs Podman vs CRI-O Benchmarks

The Incident That Made Me Rebenchmark Everything

An EKS node in us-east-1b starts flapping between Ready and NotReady. Pods on that node enter CrashLoopBackOff. The kubelet logs show context deadline exceeded against the CRI socket. Twelve minutes into the incident the node comes back, the pods recover, and the alert closes itself. Twenty-two hours later, the same pattern on a different node. By the end of the week we had correlated the symptom to sustained high docker ps latency on nodes with 200+ pods running on top of dockerd + cri-dockerd + containerd. Three layers of daemon, each one queuing calls from the kubelet, with no individual component slow enough to page.

The fix was not a tuning knob. It was removing a layer. We migrated those nodes from Docker with cri-dockerd to containerd directly. Node flapping stopped inside a week. Median pod start time dropped from 340 ms to 180 ms. Memory overhead per node fell by roughly 75 MB. That incident sent me down the rabbit hole of benchmarking what actually runs underneath a Kubernetes Pod, and whether the choices we make when installing a cluster from a tutorial are really the right ones in production.

This article is the result: four runtimes -- Docker, containerd, Podman, CRI-O -- benchmarked across six dimensions on identical hardware, with the failure modes and decision framework I wish I had during that incident. The results upend a few common assumptions about which runtime is "fastest".

The Stack Underneath Your Containers

When someone says "Docker runs my containers" the execution chain is longer than the sentence suggests. Docker CLI sends requests to dockerd, which delegates to containerd, which calls runc to create the actual Linux processes. That is three daemons and a syscall layer for every docker run. Each component is well written; the stack is not the problem. The problem is that only the last two layers are doing work the kernel cares about. The other two are forwarding requests.

Container runtimes split into two tiers:

• High-level runtimes (containerd, CRI-O) manage images, snapshots, container metadata, and expose an API (gRPC for containerd, CRI for CRI-O) to orchestrators like the kubelet.
• Low-level runtimes (runc, crun) translate an OCI spec file into actual namespaces, cgroups, and a process tree. This is the thin shim over Linux kernel syscalls.

Docker is a legacy "do-everything" package: a CLI, a build system (BuildKit), networking, Swarm, and its own API -- on top of the same containerd and runc everyone else uses. Podman flips the model by removing the long-lived daemon entirely. CRI-O does the opposite: it implements only the CRI for Kubernetes and nothing else. These architectural choices cascade into every benchmark that follows.

Architecture Comparison

Before diving into benchmarks, you need to understand how each runtime is structured. Architecture dictates overhead, security boundaries, and operational complexity.

Runtime	Architecture	Daemon	CRI Support	Primary Use Case
Docker	dockerd + containerd + runc	Yes (dockerd + containerd)	Via cri-dockerd shim	Developer workstations, CI/CD
containerd	containerd + runc (gRPC API)	Yes (containerd)	Native CRI plugin	Kubernetes nodes, cloud providers
Podman	Fork-exec model, no daemon	No	No (not designed for K8s)	Developer workstations, rootless containers
CRI-O	CRI-only daemon + runc/crun	Yes (minimal)	Native (CRI-only interface)	Kubernetes nodes (OpenShift default)

Docker (dockerd + containerd + runc)

Docker's architecture is the most layered. The Docker daemon (dockerd) manages the Docker API, networking, volumes, and build operations. It delegates container execution to containerd, which in turn delegates to runc. This three-layer stack provides the richest feature set -- Docker Compose, BuildKit, integrated networking -- but carries the highest memory overhead and the largest attack surface. A vulnerability in dockerd can compromise all containers on the host because the daemon runs as root and manages all container state.

containerd (gRPC API)

Containerd strips away the Docker-specific layers (Compose, build, swarm) and exposes a gRPC API for container lifecycle management. It handles image pulling, storage (snapshotter), and delegates to runc for execution. Every major cloud Kubernetes provider -- EKS, GKE, AKS -- uses containerd as the default runtime. It supports namespaces, plugins, and advanced features like lazy image pulling via eStargz. The daemon footprint is significantly smaller than Docker's full stack.

Podman (Fork-Exec, No Daemon)

Podman takes a fundamentally different approach: no daemon. Each podman run command forks a new process that directly manages the container via conmon (container monitor) and runc or crun. This means no single point of failure, no persistent root daemon, and containers can run entirely in user namespaces (rootless by default). The trade-off is that there is no centralized state manager -- listing containers requires scanning the filesystem, and there is no persistent API for orchestrators to connect to (though Podman does offer a Docker-compatible API socket via podman system service).

CRI-O (CRI-Only)

CRI-O implements exactly the Kubernetes Container Runtime Interface and nothing else. It does not expose a general-purpose container API, does not support docker build, and does not run standalone containers outside of Kubernetes. This laser focus results in the smallest daemon footprint and tightest security posture. CRI-O is the default runtime for Red Hat OpenShift and is purpose-built for Kubernetes node operations. It supports crun as an alternative low-level runtime, which is written in C and offers measurably faster container creation than runc (written in Go).

Benchmark Methodology

All benchmarks were run on identical bare-metal hardware: AMD EPYC 7763 (64 cores), 256 GB DDR4 ECC RAM, NVMe SSD (Samsung PM9A3), running Ubuntu 24.04 LTS with kernel 6.8. Each test was repeated 50 times, and the results below report the median with p95 values in parentheses. The container image used was alpine:3.20 (3.5 MB) for cold/warm start and memory tests, and nginx:1.27-alpine (45 MB) for image pull and networking tests.

1. Cold start -- time from run command to first process execution inside the container, with no cached image layers
2. Warm start -- same measurement with all image layers cached locally
3. Memory footprint -- resident set size (RSS) of the runtime daemon/process and per-container overhead
4. Container density -- maximum number of idle Alpine containers on 16 GB RAM before OOM
5. Image pull speed -- time to pull nginx:1.27-alpine from Docker Hub with a cold registry cache
6. CPU overhead -- CPU time consumed by the runtime during 1,000 sequential container create-start-stop-delete cycles

Cold Start and Warm Start Benchmarks

Runtime	Cold Start (median)	Cold Start (p95)	Warm Start (median)	Warm Start (p95)
Docker	1,420 ms	1,780 ms	340 ms	510 ms
containerd (ctr)	980 ms	1,250 ms	180 ms	260 ms
Podman	1,150 ms	1,520 ms	280 ms	420 ms
CRI-O + crun	920 ms	1,180 ms	150 ms	220 ms

CRI-O with crun as the low-level runtime wins both cold and warm start benchmarks. The cold start advantage over Docker is 35%, and warm start is 56% faster. containerd is close behind CRI-O because they share similar architecture -- CRI-O is essentially a stripped-down containerd with less overhead. Docker's additional dockerd layer adds measurable latency: every container operation passes through an extra daemon hop.

Podman's fork-exec model performs well on cold starts (no persistent daemon to route through) but is slightly slower on warm starts because each invocation must initialize process state from scratch rather than using a warm daemon with cached metadata.

Pro tip: If you are using containerd or CRI-O, switch the low-level runtime from runc to crun for a 10-20% improvement in container creation time. crun is a drop-in replacement written in C that produces smaller shim processes and initializes faster.

# Check your current low-level runtime
crictl info | jq '.config.containerd.runtimes.runc.runtimeType'

# Switch containerd to use crun (in /etc/containerd/config.toml)
# [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
#   runtime_type = "io.containerd.runc.v2"
#   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
#     BinaryName = "/usr/bin/crun"

# Restart containerd after config change
sudo systemctl restart containerd

Memory Footprint

Runtime	Daemon RSS	Per-Container Overhead	Notes
Docker	~120 MB (dockerd + containerd)	~12 MB	Two persistent daemons
containerd	~45 MB	~8 MB	Single daemon + shim per container
Podman	0 MB (no daemon)	~10 MB	conmon process per container (~3 MB)
CRI-O	~30 MB	~7 MB	Minimal daemon, smallest shim overhead

Docker's combined daemon footprint of ~120 MB is a fixed tax you pay regardless of how many containers are running. On resource-constrained nodes (edge devices, small VMs), that overhead matters. Podman's zero-daemon architecture looks attractive on paper, but each container's conmon monitor process adds ~3 MB, so the per-container cost is slightly higher than containerd or CRI-O.

Container Density Test

Maximum idle Alpine containers on a 16 GB RAM node (cgroup limit enforced, no swap):

Runtime	Max Containers	Runtime Overhead at Max
Docker	1,180	~1.9 GB
containerd	1,520	~1.1 GB
Podman	1,340	~1.4 GB
CRI-O + crun	1,650	~0.8 GB

CRI-O achieves 40% higher container density than Docker on the same hardware. For Kubernetes clusters running many small pods (sidecar-heavy microservice architectures), this translates directly to fewer nodes and lower infrastructure cost.

Image Pull Speed and Lazy Pulling

Runtime	Standard Pull (nginx)	eStargz Lazy Pull	Time to First Request
Docker	4.2 s	Not supported	4.8 s
containerd	3.8 s	1.1 s	1.6 s
Podman	4.5 s	Not supported natively	5.1 s
CRI-O	3.9 s	1.2 s	1.7 s

Lazy pulling with eStargz (enhanced Stargz) is a game-changer for large images. Instead of downloading the entire image before starting the container, the runtime pulls only the file entries needed at startup and fetches the rest on demand. containerd and CRI-O both support this via the Stargz snapshotter plugin. For a 500 MB application image, lazy pulling can reduce time-to-first-request from 15 seconds to under 3 seconds.

# Convert an existing image to eStargz format
ctr-remote image optimize --oci docker.io/library/nginx:1.27 \
  docker.io/yourrepo/nginx:1.27-esgz

# Pull with lazy pulling enabled (containerd with stargz snapshotter)
ctr-remote image rpull --plain-http docker.io/yourrepo/nginx:1.27-esgz

CPU Overhead for Lifecycle Operations

Total CPU time consumed by the runtime during 1,000 sequential container create-start-stop-delete cycles:

Runtime	Total CPU Time	Per-Cycle Average
Docker	142 s	142 ms
containerd	78 s	78 ms
Podman	118 s	118 ms
CRI-O + crun	64 s	64 ms

CRI-O with crun uses 55% less CPU than Docker for lifecycle operations. In CI/CD environments where thousands of containers are created and destroyed per hour, this overhead compounds. containerd is close to CRI-O, while Podman's fork-exec model (initializing a new process for each operation) costs more CPU than daemon-based approaches for high-frequency operations.

Networking Performance

TCP throughput between two containers on the same host using iperf3, with the default bridge network configuration for each runtime:

Runtime	Throughput (Gbps)	Latency (p50)
Docker (bridge)	18.2	42 us
containerd (CNI bridge)	19.8	38 us
Podman (netavark)	19.1	40 us
CRI-O (CNI bridge)	19.7	39 us

Networking performance is largely comparable across all four runtimes because the kernel handles the actual packet forwarding. Docker's slightly lower throughput comes from its docker-proxy userspace process for port mapping, which adds overhead for published ports. containerd and CRI-O use CNI plugins that operate entirely in kernel space. Podman switched from CNI to netavark (a Rust-based network stack) in version 4.0, which delivers performance on par with kernel-space CNI.

Operational Feature Comparison

Feature	Docker	containerd	Podman	CRI-O
Image Building	BuildKit (native)	BuildKit (standalone)	Buildah (integrated)	None (use Buildah)
Compose Support	Docker Compose v2	nerdctl compose	podman-compose	None
Rootless Mode	Supported (not default)	Supported (not default)	Default	Supported
Seccomp Profiles	Default + custom	Default + custom	Default + custom	Default + custom
SELinux Support	Supported	Supported	Native	Native
Log Drivers	json-file, syslog, journald, etc.	CRI log format	journald (default), k8s-file	CRI log format
Systemd Integration	Service unit	Service unit	podman generate systemd	Service unit
Windows Support	Docker Desktop	Limited	WSL2 only	No

How to Choose: A Decision Framework

Follow these steps to select the right runtime for your environment:

1. Identify your primary context -- Are you running Kubernetes in production, developing locally, running CI/CD pipelines, or deploying to edge/IoT devices?
2. Evaluate your Kubernetes version -- Kubernetes 1.24+ removed dockershim. If you are running Docker as your K8s runtime, you now need the cri-dockerd adapter, which adds complexity and latency. Migrating to containerd or CRI-O is strongly recommended.
3. Assess your security requirements -- If rootless containers are mandatory (multi-tenant environments, shared CI runners), Podman is the strongest choice with rootless as the default. containerd and CRI-O support rootless mode but require additional configuration.
4. Consider your tooling dependencies -- If your workflow depends on Docker Compose, BuildKit layer caching, or Docker-in-Docker patterns, switching to containerd or CRI-O requires reworking those workflows. Podman offers the smoothest migration from Docker for developer workstations (alias docker=podman).
5. Measure your density requirements -- If you are running high pod counts per node (500+), CRI-O or containerd will give you 25-40% more headroom than Docker. Run the density benchmark on your actual workload to quantify the difference.

# Quick benchmark: measure warm start time on your system
# Docker
time docker run --rm alpine:3.20 /bin/true

# Podman
time podman run --rm alpine:3.20 /bin/true

# containerd (via nerdctl)
time nerdctl run --rm alpine:3.20 /bin/true

# Compare container overhead
# Docker daemon memory
ps aux | grep dockerd | awk '{print $6/1024 " MB"}'

# containerd daemon memory
ps aux | grep containerd | grep -v shim | awk '{print $6/1024 " MB"}'

Failure Modes I've Seen in Production

The benchmark numbers are only useful if you know where each runtime actually breaks. These are the incidents that changed my defaults.

Docker + cri-dockerd: The Double-Daemon Deadlock

Described in the incident at the top of this article. With cri-dockerd translating CRI calls into Docker API calls and the Docker daemon translating them into containerd calls, any single slow operation creates head-of-line blocking across all three queues. Typical triggers: a stuck image pull, a container with a huge --log-opt max-size rotating, or a runaway exec. Symptom: kubelet PLEG is not healthy warnings and intermittent node flapping. Fix: move off cri-dockerd entirely; use containerd directly.

containerd: Snapshotter Leaks on Failed Pulls

When an image pull is interrupted (network blip, registry 500, OOM kill), containerd occasionally leaves behind orphaned snapshots under /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots. These accumulate and can consume tens of GiB over months. Detect with ctr snapshot ls | wc -l compared to running containers. Fix with ctr snapshot prune. On EKS or GKE nodes with 100 GiB disks, this can look like mysterious disk-pressure evictions.

Podman: Rootless Networking OOM Under Load

Rootless Podman uses slirp4netns or pasta for networking. Under sustained high throughput (greater than 5 Gbps), slirp4netns consumes nearly a full CPU core of userspace. On nodes with cpu.max limits applied to the user session, the networking stack throttles, packets drop, and the symptom looks like an application bug. Switch to pasta (podman run --network pasta) for roughly 2-3x throughput and a fraction of the CPU cost.

CRI-O: Log Rotation Gotcha

CRI-O writes Pod logs to /var/log/pods/<namespace>_<pod>_<uid>/<container>/0.log and relies on the kubelet's log rotation (--container-log-max-size, --container-log-max-files). Mis-configured kubelet flags (the default of 10 MiB/5 files is often too small for chatty applications) fill the node disk. Unlike Docker's built-in json-file driver, there is no runtime-level fallback. Always check kubelet log rotation configuration on CRI-O nodes.

runc CVE-2024-21626: File-Descriptor Leak

A real-world runc escape CVE from January 2024 allowed a malicious image to break out via leaked file descriptors. Affected every runtime using runc (Docker, containerd, CRI-O). Fix: upgrade runc to 1.1.12 or later. Better: switch to crun, which is not susceptible to the same class of bug because it does not carry the Go runtime's fd behaviour. This is the kind of incident that nudges security-sensitive teams toward CRI-O + crun as a baseline.

Cost and Density Impact on a Real Cluster

Switching runtimes is not free -- there is a migration window, testing effort, and coordination with platform tooling. The savings have to justify it. Here is a worked example for a 50-node EKS cluster running a typical microservice platform (200 pods per node on average):

Metric	Docker + cri-dockerd	containerd direct	CRI-O + crun
Memory overhead per node (daemons)	~135 MB	~45 MB	~30 MB
Pods per m7i.2xlarge (32 GiB) before eviction risk	~185	~210	~230
Nodes needed for 10,000 pods	54	48	44
Monthly cost (m7i.2xlarge $0.4032/h)	$15,881	$14,116	$12,940
Annualised delta vs Docker	-	-$21,180	-$35,292

The density gains come from lower per-node runtime overhead and faster container start times (which means less memory held by pods waiting on init containers). For a 50-node cluster the savings will not retire anyone early, but over a hundred clusters the numbers compound into real money, and the reliability improvement from eliminating the double-daemon failure mode is worth the migration on its own.

Quick Decision Matrix

Context	Pick	Why
New production Kubernetes cluster on a major cloud	containerd	Default on EKS, GKE, AKS; broadest tooling support
OpenShift or RHEL-based production Kubernetes	CRI-O	Default for OpenShift, smallest footprint, aligned with Red Hat roadmap
Security-first Kubernetes (regulated workload)	CRI-O + crun	Smallest attack surface, C-based low-level runtime avoids Go fd class of bugs
Developer laptop (macOS, Windows)	Docker Desktop	Best cross-platform experience, GUI, WSL2/HyperKit integration
Developer laptop (Linux), security-conscious	Podman	Rootless by default, no persistent daemon, near-Docker CLI
CI runner building images	containerd + BuildKit	Fast parallel builds without Docker daemon overhead
Edge / IoT device with less than 1 GiB RAM	CRI-O or containerd	Every MB matters; avoid Docker's 120 MB baseline

Frequently Asked Questions

Pick the Right Runtime for Each Context

There is no single best container runtime -- the right choice depends on context. For Kubernetes production nodes, containerd or CRI-O deliver the best performance and density with the lowest overhead; CRI-O edges ahead if you use OpenShift or want the absolute minimum footprint. For developer workstations, Podman offers the best security-to-usability ratio with rootless defaults and Docker CLI compatibility, while Docker Desktop remains the most polished experience for teams that value GUI tooling and cross-platform consistency. For CI/CD pipelines, containerd with BuildKit provides fast image building without Docker's daemon overhead. Start by identifying your primary constraint -- security, density, developer experience, or Kubernetes compatibility -- and let that drive your runtime selection.