Large container images can slow down application startup, especially when workloads run on fresh nodes or scale from a cold cache. This blog shows how to validate eStargz lazy pulling on Oracle Cloud Infrastructure (OCI) before introducing it into a production platform.
Introduction
As containerized applications grow, image pull time can become a visible part of startup latency. This is especially true for images that include large frameworks, runtime assets, or model files.
eStargz helps address this problem by enabling lazy pulling. Instead of downloading all image layers upfront, the runtime can fetch only the data needed to start the container and retrieve the rest on demand.
This blog describes a lightweight OCI-based benchmark that compares a regular container image with an eStargz-optimized version of the same image.
Why eStargz Lazy Pulling Matters
For small images, regular pulling is usually good enough. But for large images, cold pull time can become visible in application startup, scale-out events, and fresh-node scenarios.
eStargz is useful when the goal is to reduce time-to-first-run. With stargz-snapshotter, containerd can start containers from eStargz images using lazy loading instead of waiting for the complete image to be downloaded first.
How Can We Use eStargz Lazy Pulling on OCI?
To validate eStargz lazy pulling on OCI, we use a lightweight benchmark . The VM runs containerd with two snapshotter paths: the default overlayfs snapshotter for a regular image, and stargz-snapshotter for an eStargz-optimized image.
Both images are pulled from OCIR and tested on the same VM. This keeps the comparison focused on container startup.
Benchmark Architecture
What the Benchmark Shows
The benchmark compares the startup behavior of two versions of the same image. The regular image follows the traditional pull path, where the image is downloaded before startup. The eStargz image follows the lazy-pull path, where containerd can fetch only the data needed to start the container and retrieve the rest on demand.
The result helps determine whether eStargz reduces time-to-first-run for the workload being tested.
From Benchmark to Production
This VM-based setup is intended as a first validation step. It keeps the test focused on one question: can an eStargz image start faster than the regular version of the same image when both are pulled from OCIR?
If the benchmark shows a meaningful improvement, the next step is to move eStargz earlier in the container lifecycle by adding eStargz image creation to the build pipeline and publishing optimized images to OCIR.
Starting with a standalone VM avoids adding platform complexity before there is evidence that lazy pulling improves the workload.
Conclusion
eStargz is not required for every workload, but it can be valuable when image size contributes to startup latency. By testing regular and eStargz images side by side on OCI, teams can decide whether lazy pulling is worth adopting for the workloads where cold-start performance matters.
Useful Links