How Much Thumbnail and ML Storage Does Immich Need for Family Photo Backup?

Immich has no reliable thumbnail-only storage ratio, so family libraries should measure generated bytes per asset and reserve separate space for ML models.

A 2 TB family photo archive does not tell you how large its Immich thumbnail directory will become, because asset count, source resolution, thumbnail settings, video mix, and enabled models all change the derived footprint. The safer sizing method is to process a representative sample, measure thumbnails and model cache separately, project library growth, and then add operational headroom rather than treating one percentage as a universal requirement.

Separate Originals From Immich-Generated Storage

Start with a boundary: original photos and videos are only one part of the disk footprint that supports an Immich library. The server also keeps generated assets used for browsing and compatibility, while the machine-learning service keeps downloaded model files in its own cache. Those categories grow for different reasons, so combining them into one vague percentage makes it hard to see which setting or workload is actually consuming space.

A long-running Immich community sizing reference notes that thumbnails and transcoded video together can add roughly 10–20% on average. That figure is useful only as broad context: it combines two generated categories and therefore must not be presented as a thumbnail-only ratio. A photo-heavy family with little video can land somewhere very different from a video-heavy archive.

The architecture also matters when deciding where to place that extra space. ZimaSpace's look at AI photo organization treats indexing and generated data as services around the original library, not replacements for it. For capacity planning, keep the originals, thumbnail/preview area, video derivatives, database, and ML cache as separate lines even if they share one physical disk.

Measure Thumbnail Cost Per Asset Before Scaling Up

Choose a representative slice of the family library instead of the easiest thousand files. It should include the phone generations, camera resolutions, portraits, screenshots, panoramas, and other image types that make up normal use. Let thumbnail-related jobs finish, record the processed asset count, and measure the thumbnail directory. Dividing measured bytes by processed assets gives a local planning ratio that already reflects your chosen thumbnail and preview settings.

Real installations demonstrate why that local ratio matters. One Immich discussion reported 21 GB of thumbnails alongside 58 GB of encoded video in that particular system. The number is anecdotal and not a target, but it shows that derived folders can have materially different sizes and should be measured independently rather than inferred from the original library's terabytes alone.

For example, if 10,000 representative images produce 12 GB of thumbnails and previews, your observed rate is about 1.2 MB per asset. A projected 60,000-image library would therefore point to roughly 72 GB at the same settings before growth margin. Re-run the sample after changing thumbnail resolution or quality, because those changes invalidate the old per-asset ratio even though the original files have not changed.

ML Model Cache Depends More on Models Than Photo Count

Machine-learning storage behaves differently from thumbnails. The model cache primarily holds model files that the ML service downloads and reuses, so its disk footprint is driven more by which smart-search and face-recognition models you select than by whether the library has 20,000 or 200,000 photos. The library size changes how much processing occurs, but it does not require a fresh copy of the model for every asset.

A recent self-hosted Immich deployment describes a persistent model cache mounted for the machine-learning service and reports that the models used there occupied less than 1 GB in total. That is one configuration, not a guarantee. The important mechanism is persistence and reuse: once the selected files are present, normal photo-count growth does not multiply the model binaries.

For a family server that may change models later, a larger planning allowance is sensible than the smallest currently observed cache. An Immich maintainer has suggested that storage on the order of 10 GB is generally enough, depending on model choices. Treat that as a conservative starting allowance rather than a requirement, then replace it with the actual cache size from your running configuration after the first ML jobs have completed.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Video Mix and Client Caching Can Break a Photo-Only Estimate

The thumbnail-plus-ML estimate stops being a useful description of total storage when the library contains substantial video or when you are looking at device-local app storage. Video compatibility can create large server-side derivatives, while phone and browser caches occupy client storage that is not part of the server's thumbnail directory or ML model cache. Mixing those numbers can make a normal thumbnail estimate appear wildly wrong.

A large-library user report illustrates the boundary: a roughly 2.4 TB library with 179,000 photos and 19,000 videos reported 822 GB of server derivatives for thumbnails plus transcoded video, while the Android app also accumulated tens of gigabytes locally. This is an anecdote, not a sizing rule, but it shows how video and client caching can dominate a simple photo-only model.

Keep the categories separate when you measure: server thumbnail/preview data, encoded video, ML model cache, database, and client-local cache. If thumbnail storage looks unexpectedly large, inspect the thumbnail directory itself rather than the whole Immich data tree. If encoded video is the dominant folder, the relevant planning question has changed from photo indexing overhead to video compatibility and transcoding policy.

Use a Sample-and-Growth Formula for Family Storage

Use three inputs: measured thumbnail bytes per representative asset, projected image count over the next one to two years, and measured ML model-cache size. Multiply the first two, add the model cache, then add an operational cushion for regeneration, settings changes, and ordinary filesystem growth. A 20–25% cushion is a planning heuristic here, not an Immich requirement; users with tight disks should measure more often instead of assuming the cushion will always be sufficient.

A conservative model-cache ceiling can start from the maintainer's guidance that about 10 GB should generally be enough depending on model choice. Combine that with your own thumbnail measurement, not the 10–20% thumbnails-plus-transcodes figure. For a 72 GB projected thumbnail footprint, 10 GB model allowance, and 25% cushion, the planning reserve would be about 103 GB.

Recalculate when any variable that drives the estimate changes: thumbnail resolution or quality, a major camera-resolution shift, a different ML model, large video growth, or a substantial increase in family members uploading assets. The decision threshold is simple: if projected generated storage plus the cushion approaches the free space available on the intended fast volume, move the derivative path, add capacity, or reduce the relevant generation settings before the library reaches that point.