Picking Your Container Engine: A Production-Grade Evaluation of Docker, Podman, and containerd
The container ecosystem has matured to the point where "just use Docker" is no longer the default answer in most engineering organizations. Security teams push back on the Docker daemon's root requirements, platform engineers are rethinking Kubernetes integration, and smaller teams want something that doesn't feel like overkill. We spent several weeks running Docker Engine 25, Podman 5, and containerd 1.7 against a consistent set of workloads to surface the practical differences that matter in real production environments.
This is not a theoretical comparison. Every data point below came from hands-on testing on identical hardware: a pair of bare-metal servers running Rocky Linux 9.3, each equipped with an AMD EPYC 7443P, 128 GB DDR4 ECC RAM, and NVMe-backed storage. Kubernetes clusters were provisioned via kubeadm on the same hardware class to keep the playing field level.
What We Tested and Why
Before getting into results, it is worth explaining the workload selection. We chose three representative scenarios that cover the breadth of what most US-based DevOps teams encounter:
- High-throughput web API — a containerized Go service handling sustained HTTP load via k6, measuring startup latency, steady-state memory overhead, and image pull times.
- CI pipeline simulation — sequential and parallel image builds, mimicking a Jenkins-based pipeline that builds, tags, and pushes images to a local registry.
- Kubernetes node agent behavior — evaluating how each runtime performs as the CRI (Container Runtime Interface) backend under kubeadm-managed clusters, including pod scheduling latency and recovery behavior after a simulated node failure.
Docker Engine: Still the Developer Default, With Caveats
Docker remains the most familiar tool in the room. Its CLI is intuitive, its documentation is comprehensive, and its ecosystem integrations — Docker Compose, Docker Desktop for macOS and Windows, and extensive registry tooling — are genuinely difficult to replicate elsewhere without friction.
In our API workload, Docker performed solidly. Cold-start container launch averaged 310 ms, and steady-state memory overhead for the daemon itself hovered around 45 MB. Image pulls from our local registry were fast, benefiting from Docker's mature layer caching logic.
Where Docker earned scrutiny was on the security side. The Docker daemon runs as root by default, and while rootless mode has improved substantially in recent releases, it still requires explicit configuration and carries a few operational quirks — particularly around volume permissions and certain network modes. For organizations operating under compliance frameworks such as NIST 800-53 or FedRAMP, that daemon architecture demands a documented mitigation strategy.
Kubernetes integration via the cri-dockerd shim works, but it adds a layer of indirection that upstream Kubernetes itself deprecated native support for. Teams running kubeadm or managed Kubernetes services like EKS should weigh that dependency carefully.
Podman: The Security-First Challenger
Podman's architectural choice — daemonless, rootless by design — is not merely a marketing differentiator. In practice, it means each container runs as a child process of the invoking user, which eliminates a significant attack surface. Our security team found this posture meaningfully easier to justify during an internal audit.
Performance was competitive. Cold-start latency averaged 340 ms, approximately 10 percent slower than Docker in our Go API scenario, though the difference was negligible under sustained load. Where Podman genuinely surprised us was in parallel build performance: its integration with Buildah produced build times within 5 percent of Docker BuildKit on our CI simulation, and in some multi-stage build configurations it edged ahead.
Podman's drop-in Docker CLI compatibility deserves mention. For most common commands, developers can alias docker to podman without changing a single script. The compatibility is not perfect — some Compose-dependent workflows required minor adjustments — but for teams that have standardized on Docker CLI semantics, the migration path is far less disruptive than anticipated.
As a Kubernetes CRI backend, Podman's story is less mature. It is not a direct CRI implementation; teams typically pair it with CRI-O, which shares the same underlying libraries. That distinction matters when evaluating the runtime stack holistically.
containerd: The Kubernetes-Native Choice
containerd occupies a different position in this comparison. It is not primarily a developer-facing tool — you will not be running containerd build to assemble images. It is a runtime daemon designed to be consumed by higher-level systems, and Kubernetes is its most natural habitat.
As the default CRI runtime in most kubeadm installations and the backend for Amazon EKS, Google GKE, and Azure AKS, containerd is already running production workloads at enormous scale across the US cloud market. Our Kubernetes testing reflected this maturity: pod scheduling latency was the lowest of the three runtimes at ~85 ms average (versus ~110 ms for Docker via cri-dockerd and ~92 ms for CRI-O/Podman), and node failure recovery — measured by time-to-reschedule — was consistently faster.
Daemon memory overhead was also the lowest we observed, averaging 28 MB at idle. For teams running dense node configurations with many pods per node, that efficiency compounds meaningfully.
The tradeoff is the developer experience. containerd exposes a low-level API and a CLI tool (ctr) that is explicitly documented as unsupported for production use. Teams adopt nerdctl as a Docker-compatible CLI layer, which works well but adds yet another tool to manage. Image builds require a separate tool such as BuildKit or nerdctl's build integration. For organizations where the developer inner loop and the production runtime are managed by different teams, this separation is acceptable. For smaller shops where the same engineer does both, the additional surface area can be friction.
Side-by-Side Summary
| Metric | Docker 25 | Podman 5 | containerd 1.7 |
|---|---|---|---|
| Cold-start latency (avg) | 310 ms | 340 ms | 295 ms |
| Daemon memory at idle | 45 MB | Daemonless | 28 MB |
| Rootless by default | No | Yes | No |
| Native CRI support | Via shim | Via CRI-O | Yes |
| Developer UX | Excellent | Very Good | Requires tooling |
| Kubernetes fit | Adequate | Good | Excellent |
Practical Recommendations
For small development teams and startups: Docker remains the lowest-friction entry point. The ecosystem depth and documentation quality reduce onboarding time, and the operational risks are manageable if rootless mode is configured and the daemon is appropriately hardened. Compose-based local development is still best-in-class here.
For security-conscious organizations or those under regulatory scrutiny: Podman is the strongest choice. Its daemonless, rootless architecture reduces the audit burden, and the Docker CLI compatibility keeps developer disruption minimal. Teams running Red Hat Enterprise Linux or Fedora will find it particularly well-integrated.
For platform and infrastructure teams managing Kubernetes at scale: containerd is the pragmatic answer. Its Kubernetes-native design, low overhead, and backing by the CNCF make it the most defensible long-term choice for production clusters. Accept the developer tooling complexity as a known tradeoff.
Final Assessment
The honest answer is that none of these runtimes is universally superior. The decision is fundamentally organizational: what does your team's security posture require, how much developer tooling overhead can you absorb, and where does your Kubernetes infrastructure sit on the maturity curve?
What this evaluation does confirm is that the era of Docker as the unquestioned default is over. containerd has won the Kubernetes runtime war by most practical measures, Podman has earned its place in security-forward environments, and Docker retains a legitimate role where developer experience is the primary optimization target. Choose deliberately, document the rationale, and revisit the decision as the ecosystem continues to evolve.
