Docker image sizes in 2026: a measurement, and why no trend exists

On 27 August 2026 we queried official image sizes through the public Docker Hub API — linux/amd64, compressed size, which is what actually travels over the network:

Base images for scale: alpine 3.7 MiB, busybox 2.1, debian:stable-slim 28.4, ubuntu 39.6. Application images: nginx 60.4, redis 52.9, mysql 259.7, mongo 321.1, wordpress 262.0.

Across 22 official images tagged latest: minimum 2.1 MiB, first quartile 42.3, median 80.5, third quartile 260.3, maximum 422.5, mean 136.3.

Caveat: these are Docker Official Images, not a slice of the registry. It is a convenience sample of popular images and says nothing about Docker Hub’s long tail.

First: the variant decides, version drift does not. The gap between full and alpine runs from 5× to 24×. Growth across major versions over several years: python 3.9 → 3.13 up 1.9%, node 18 → 24 up 3.5%, golang 1.21 → 1.25 up 2.8%. Image size is an architectural decision, not a consequence of ageing.

Second: the alpine saving collapses on data-bearing images. For python the switch gives 24×; for postgres, 1.4×. "Use alpine" is sound advice for language runtimes and nearly useless for application images where the weight is binaries and data, not system scaffolding.

Third: "minimal" does not mean "few layers". The distroless/python3 image weighs 18.8 MiB across 43 layers — more than any Docker Official Image in our sample. Layer count is not a proxy for size, though it is often used as one.

For comparison, the other distroless images: static 0.68 MiB across 12 layers, base 7.79 across 14, java21 60.25 across 30.

The only measurement of sizes and layers across the whole registry was made in May 2017: 355,319 images from 457,627 public Docker Hub repositories. The median then was 94 MB uncompressed and 17 MB compressed; ninety percent of images had fewer than 18 layers, with a mode of 8.

Nobody has repeated that since. The only ecosystem crawl carrying 2026 data covered 12.7 million Docker Hub repositories, but it was built for security purposes and publishes neither sizes nor layer distributions.

So no trend line exists for 2023–2026, and substituting the 2017 figure as current is not permissible. Nor does any percentage breakdown of alpine versus slim versus distroless versus full across a large corpus exist — nobody publishes that for any date.

What is known about base images indirectly: by pull count as of 27 August 2026, busybox 12.78B, alpine 12.16B, ubuntu 10.03B, debian 1.71B. Distroless is absent from those statistics — it lives in a different registry and is not comparable.

"Typical size" tables from vendors of minimal images are not measurements: they carry no methodology, no image count and no measurement date. One telling detail — in one such table the vendor’s own image is listed as larger than alpine.

The claim that "image sizes grew fivefold" traces to a sentence about a fivefold rise in bloat — the share of unused packages inside an image. That is not megabytes, and that report has never measured size in megabytes at all.

What is solid about excess: more than half of the twenty most-pulled application containers carry over 60% unused files (tags from late 2024, a sample of twenty images — too few for a population estimate, enough to establish the order of magnitude).

And a category of its own — machine-learning images: across 739 built images the median is 5.69 GB against a mean of 10.27 GB, with the base image accounting for only 16–21% of the weight and the rest being the project’s own layers. The data is from roughly 2024, published in July 2026.

The measurements are reproducible: the Docker Hub API returns per-platform sizes in a single request.