AskMeAnything
Ask
Ask
27
@pulled_45_images ·

Pulled the numbers for 45 official images: the alpine variant is a median of 2.3x smaller and python is 23x

Everyone repeats that alpine images are smaller. Nobody says by how much, so I pulled the published sizes for 45 official images and worked it out.

Median ratio between latest and alpine: 2.3x. Which is much less dramatic than the folklore, until you look at the spread, because the spread is the whole story.

The extremes, latest to alpine:

  • python 395.7 MB → 16.9 MB (23.4x)
  • erlang 642.6 → 54.0 (11.9x)
  • elixir 650.3 → 61.7 (10.5x)
  • ruby 409.0 → 47.7 (8.6x)
  • node 422.4 → 60.5 (7.0x)
  • memcached 30.7 → 5.7 (5.4x)

Only 20 of the 45 publish an alpine variant at all. Nine publish slim, and there the median ratio is 5.2x, which makes slim the better default for anything where alpine's libc is a problem: swift goes 1193.9 MB → 96.4 MB, perl 376.9 → 59.1.

Median latest across all 45 is 167.6 MB. Largest is swift at 1.19 GB, then sonarqube at 1.03 GB. Smallest is busybox at 2.1 MB.

One caveat that matters: these are compressed sizes, what you download. On disk, uncompressed, everything here is bigger, and the ratio between variants does not survive the change unchanged either.

11 answers Share
Report

11 answers

BestTopNewOldControversial

Answering anonymously, a moderator will review it first.

  • @distroless_now · 2w ago · 2 replies
    @distroless_now ·

    Worth adding a third option since the thread is a two-way comparison. Distroless is smaller than slim, has no shell and no package manager, and the attack surface argument is stronger than the size argument.

    The cost is real: you cannot exec into it to debug, which people discover during an incident rather than before one. Have a debug variant ready or you will be rebuilding under pressure.

    22
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @cold_start_vps · 2w ago
      @cold_start_vps ·

      Also worth knowing your platform supports pulling a debug image quickly. Ours does not and that changed the calculation.

      10
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
  • @musl_burned_me · 2w ago · 3 replies
    @musl_burned_me ·

    The python number is real and it is also the single worst image to pick alpine for, which is a genuinely funny result.

    Alpine uses musl instead of glibc. Any Python package with a compiled component either has no prebuilt wheel for musl or has one that is less tested, so pip falls back to building from source. Your 16.9 MB base then pulls a compiler toolchain, and the final image is bigger than the slim one you skipped, and the build takes eleven minutes.

    The base image size is the number people compare. The final image size is the number that matters and it goes the other way.

    28
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @alpine_convert · 2w ago
      @alpine_convert ·

      Fair, though it depends entirely on what you install. A pure-Python service on alpine stays small and builds fine. It is the scientific stack that turns it into a compiler exercise.

      12
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
    • @pulled_45_images · 2w ago
      @pulled_45_images OP ·

      This is the caveat the ratio hides completely, and it is worst exactly where the ratio looks best.

      15
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
  • @layer_cache_nerd · 2w ago · 3 replies
    @layer_cache_nerd ·

    Base image size matters much less than people think for deploy speed, because layers are cached. You pull the base once per host and then push a few megabytes of application layer per deploy.

    Where it does matter: first deploy on a new host, autoscaling that adds hosts under load, and any CI that starts from a cold cache. If none of those apply, this is an argument about numbers you only pay once.

    20
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @registry_bill · 2w ago
      @registry_bill ·

      And registry storage, which is the invoice nobody reads. Multiply the difference by every tag you keep and every branch that builds an image, and a 400 MB base becomes a real monthly number.

      13
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
    • @pulled_45_images · 2w ago
      @pulled_45_images OP ·

      Fair. The one-off framing is right for a stable fleet and wrong for anything that scales out.

      1
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
  • @cold_start_vps · 2w ago
    @cold_start_vps ·

    On a small VPS with a slow disk the difference is felt rather than measured. Pulling 400 MB against 17 MB on a constrained box is the gap between a deploy you watch and one you wait through.

    1
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
  • @alpine_convert · 2w ago
    @alpine_convert ·

    Compressed versus on-disk is the caveat I would put in bold. People quote pull sizes and then run out of disk.

    1
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
  • @registry_bill · 2w ago
    @registry_bill ·

    Only 20 of 45 offering alpine at all is the number that surprised me most.

    1
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report