Why we choose Podman over Docker

Our hosting platform creates, destroys and execs into containers all day. The container runtime is our substrate, not a developer convenience. So we benchmarked both runtimes on the workload we actually run. Here's what we found, including the places Docker won.

Inventient is built as a single-binary hosting platform: one process containing the proxy, the control plane and the workers, orchestrating customer workloads as containers. That architecture puts unusual pressure on one decision most teams never revisit: which container runtime sits underneath everything.

For a development laptop, Docker and Podman are close to interchangeable. For a multi-tenant hosting platform, they are not. The question that mattered to us was never which runtime is more popular. It was which runtime is safer and faster for a platform that runs other people's code, all day, on shared hardware.

We answered it the only way we trust: the same OCI images, the same resource limits, the same host, twenty iterations per benchmark, each runtime tested in isolation. The workload was our real stack (a Next.js application, PostgreSQL 16 and Redis 7) on a 4-CPU, 16 GB ARM64 server. The result was a clear decision for Podman, but not a clean sweep. Both halves of that sentence are worth explaining.

Security: the architectural argument

The strongest reason to choose Podman has nothing to do with benchmark numbers. It is how the two runtimes are built.

Docker's default architecture is a long-lived daemon that runs as root. Every container is a child of that daemon, and every instruction flows through its socket. That socket is effectively a privilege-escalation API: any process that can talk to /var/run/docker.sock can mount the host filesystem or spawn a privileged container. In practice, it can own the machine. Our control plane talks to the container runtime programmatically hundreds of times an hour. We did not want that channel to be root-equivalent.

Podman inverts the model. It is daemonless, with containers started by fork/exec and supervised as ordinary processes, and rootless by default, so every workload runs as an unprivileged user. If a container escape ever happens on our platform, the attacker lands as a restricted service account, not as root. There is also no long-lived privileged process parsing untrusted API input, which simply removes a class of attack surface rather than mitigating it.

The same architecture pays a reliability dividend. When the Docker daemon crashes or restarts for an upgrade, every container on the host restarts with it. Podman containers are independent processes with no shared parent: there is no single point of failure. For a hosting platform, that is not a nice-to-have. It is a hard requirement.

Rootless isn't free; it is precisely why Docker wins one of the benchmarks below. We consider that a trade we're making deliberately, not a surprise we absorbed.

Performance: what we measured

Security would have been enough on its own, but the performance results reinforced the decision. Across the operations that dominate our hot path (starting containers, writing to disk, holding memory), Podman was consistently faster and lighter.

Each of these maps to something real in our platform. Container start time is felt on every deploy, because we create and destroy containers constantly rather than keeping long-lived ones warm. The disk I/O gap (Podman's native overlayfs against Docker's overlay2 writeback) dominates database and build workloads. And the memory numbers compound: Docker's resident daemon tax (dockerd at 93 MB plus containerd at 64 MB) is real money on a 16 GB machine running a dozen or more tenant containers, before a single workload does anything.

Where Docker won, and why we accept it

A benchmark that only reports the wins isn't a benchmark; it's marketing. Docker beat Podman in two places, and one of them deserves a careful look.

The important nuance is that the typical request is indistinguishable between the two runtimes: 83 ms versus 85 ms at the median. The gap lives entirely in the tail: roughly one request in a hundred on Podman hits a latency spike caused by pasta's userspace packet handling.

Equally important: this is a trade-off of rootless, not of Podman. Rootful Podman uses the same kernel-space bridge networking as Docker and closes the gap without giving up the daemonless architecture. In other words, the tail latency is something we can buy back at any time if service-level targets ever demand it. Today, we choose to keep rootless and accept the tail, because that is the same trade that removes the root-equivalent socket from our platform.

Docker's second win was API exec latency (42 ms vs 95 ms), which our control plane uses for shell sessions and database backups. That cost is paid once per WebSocket terminal open or per multi-second pg_dump, never on the HTTP request path, so it does not touch anything a user can feel.

Operational fit

Beyond the benchmarks, Podman simply fits the way the platform is built. Daemonless containers are ordinary processes, which means they slot cleanly under systemd like everything else we supervise. And because Podman exposes a Docker-compatible API, our Rust control plane didn't need a rewrite; it was a drop-in at the socket level. Rootless, per-user containers extend the same defence-in-depth posture we apply everywhere else in a multi-tenant environment.

Podman wins where it matters most for a hosting platform: a security architecture with no root-equivalent daemon, no single point of failure, faster container starts, dramatically faster disk I/O and a lighter memory footprint. Docker's wins are real, but they either never touch our hot path or are deliberate consequences of running rootless, consequences we could reverse with rootful Podman if our service-level targets ever required it.

Our advice to anyone facing the same decision: choose the runtime for the failure modes you can't afford, then verify the performance story on your own workload. Ours is published above.