“It works on my machine” is a dangerous phrase in our line of work. While Podman runs natively on Linux, utilizing the kernel directly, the experience on macOS and Windows is different. These platforms require a virtual machine to provide the necessary Linux environment. This virtualization layer introduces overhead that often leads to user complaints about slow build times or sluggish image imports compared to Docker. For my Master’s thesis, I did not just want to measure this feeling. I wanted to fix it. I built a benchmark orchestration system that helped drive double-digit performance gains in Podman v5.7.0.

The Solution: Automated Orchestration with TOPSAIL

To effectively benchmark real-world container workloads, I utilized Red Hat’s testing framework, TOPSAIL. This comprehensive system goes beyond manual scripts by managing the entire lifecycle: provisioning machines across Windows, macOS, and Linux, executing complex scenarios, and visualizing the results. A key objective was also to address the lack of suitable benchmarks. I created a benchmarking suite composed of two main types:

1. Real-world scenarios: These were derived from daily Podman usage and issues reported on GitHub.
2. Synthetic benchmarks: These generated artificial load to test CPU, RAM, filesystem I/O, and networking performance across various scenarios.

The primary goal of this effort was straightforward: compare the performance of Podman and Docker to pinpoint specific areas of performance gaps.

The “Aha!” Moments: From Data to Engineering Fixes

The benchmark data revealed two massive bottlenecks. This led to immediate fixes in Podman.

1. Unlocking Storage Speed

• The Problem: We noticed that removing images in parallel was surprisingly slow. It turned out that the process of removing layers from storage held a global lock during disk I/O. If you were deleting a large image, other processes were blocked from accessing storage.
• The Fix: I implemented a temporary directory structure. Instead of holding the lock while deleting files, we now rename the files to a temporary directory (which is fast), release the lock, and then delete the files asynchronously.
• The Impact: This simple change effectively removed the serialization bottleneck, allowing true concurrency.

For further details, refer to the blog post: https://blog.podman.io/2025/08/unlocking-speed-accelerating-parallel-layer-removal-in-podman-v5-6/.

2. The Local API

• The Problem: On macOS and Windows, the CLI was sending build contexts and image tarfiles over the REST API into the VM. This was essentially like uploading a file over a network, which consumed significant CPU and network resources.
• The Fix: Since the host filesystem is already mounted into the VM, we implemented a “Local API” optimization. This bypasses the API transfer entirely and lets the VM access the files directly from the mount.
• The Impact: We saw a massive reduction in time for image loading and large context builds on macOS, bringing Podman’s performance in line with user expectations.

Further details are available in this blog post: https://blog.podman.io/2025/12/faster-podman-workloads-on-macos-and-windows/

The Verdict: Podman v5.7.0 vs. Docker

In terms of overall performance, Podman and Docker are nearly identical, with differences measured in milliseconds. This margin is negligible for most users, as tens of milliseconds can be easily overshadowed by operating system activity or other applications. However, Podman significantly outperforms Docker in its interaction with image and container storage. Benchmark results on Linux clearly demonstrate this advantage. Thanks to recent improvements, these superior results for Podman are consistent across operating systems. Docker’s persistent connections still give it a slight edge in the speed of pulling images.

My thesis https://is.muni.cz/th/pyfi7/ provides the full details of the benchmark description and its corresponding results.

Conclusion

Working on this thesis with Red Hat and Podman developers was a distinct shift from the academic world to production engineering. Performance is not magic. It is engineering. While mastering the complex TOPSAIL framework and battling Windows WSL quirks was a steep challenge, the impact was worth it. By building a robust orchestration suite, I transformed performance complaints into hard data. Podman v5.7.0 is faster because of it, and we now have the tooling to investigate performance gaps.