Why Does Immich Thumbnail and ML Storage Grow During Large Mobile Imports?
Large imports usually expand Immich storage because each asset produces derivatives and database records, while downloaded models occupy a separate cache.
A family moves years of phone photos onto a home NAS, then watches free space keep falling after the upload counter finishes. That can reflect legitimate background processing rather than another copy of every original. The useful distinction is between files generated per asset, shared model files, and growth that continues without a corresponding increase in completed work.
One Upload Creates Several Kinds of State
The uploaded original is only one part of the resulting library. Immich also prepares smaller representations for browsing and stores information that connects the asset to its owner, dates, albums, and search features. These outputs serve different requests, so finishing the network transfer does not mean every downstream write has already happened.
The division between media files and database records matters here: application metadata and search embeddings live in PostgreSQL, rather than being extra full-resolution photographs. The machine-learning service computes results used by the application. Treating all additional bytes as duplicated originals therefore gives the wrong explanation for ordinary import growth.
Consider a phone finishing its transfer while the server still processes the accepted batch. Originals may already be stable on disk, but previews and searchable records can continue appearing. Compare storage measurements at the same processing stage; an immediately uploaded cohort and a fully processed cohort are not equivalent samples.
Asset Count Explains More Than Original Gigabytes
For thumbnail planning, the number and type of assets often explain more than the total original gigabytes. A thousand small photographs and a handful of long videos can occupy similar source capacity but require very different numbers of image derivatives. Preview dimensions, compression settings, and image content further change the generated bytes.
Published thumbnail measurements illustrate that variation: one owner reported 6.3 GB for a 70 GB library, while another reported about 370 GB for 2 TB of photos and videos. Those are individual configurations, not comparable controlled benchmarks. They demonstrate why adopting a single percentage from a forum can misrepresent another household.
As an illustrative calculation, 100,000 assets averaging 250 KB of measured image derivatives require about 25 GB in decimal units. At 500 KB each, the same count needs about 50 GB. Neither figure includes originals, encoded video, database growth, or backups; the example isolates the per-asset relationship rather than recommending a universal allowance.
Model Files and Search Records Grow Differently
The model cache contains reusable model files, whereas search vectors represent individual assets. With a fixed set of downloaded models, adding more photos does not require downloading a fresh complete model for every image. Adding or changing models can instead increase cache storage in steps, independently of the number of uploaded photographs.
A firsthand portable deployment keeps the library, model cache, and PostgreSQL data in separate persistent directories. That separation makes each storage role observable without assuming that one combined Docker size represents machine-learning output. It is a layout example from an older release, not a current installation recipe or a recommended set of container tags.
Distinguish disk usage from loaded memory as well. A model can remain on disk while its in-memory copy is unloaded, and filesystem caching can raise reported memory without creating more persistent files. To explain a jump, identify the owning directory and the changed setting before drawing conclusions from a container name.
Where Normal Growth Stops Being an Explanation
Normal derivative growth has a bounded input: a fixed cohort of originals processed under fixed settings. It should not create an endlessly expanding population of new source assets. If asset counts keep increasing after all intended imports stop, the explanation needs to include discovery paths, repeated ingestion, or another source of new work.
A confirmed recursive scanning case included the Immich upload location inside an external library. Generated thumbnails were then treated as new images, creating more derivatives of derivatives. This is a different causal mechanism from a large mobile upload and must not be used as evidence that every sizable library naturally multiplies without limit.
Unusual growth in a container writable layer is another separate category. A 2026 report described hundreds of gigabytes accumulating there; the discussion did not establish a universal root cause. Do not delete database files, media, or Docker internals to make a graph look normal. First establish which role is growing and whether completed work explains it.
Measure the Import by Storage Role
Record original asset count and bytes, thumbnail and preview bytes, encoded-video bytes, database size, model-cache size, and any temporary or log growth before a representative import. Repeat after that same cohort has completed the enabled processing jobs. Keep media settings unchanged so differences can be attributed to the import rather than a simultaneous configuration change.
Storage accounting does not replace a family backup plan. A usable photo service needs protected originals and the application state required to reconstruct the library; a thumbnail directory alone cannot preserve the household collection. Keep this protection task separate from measuring regenerable overhead so a space-saving experiment cannot become the only copy of a memory.
Accept the result when the measured role totals explain the added bytes and no unexpected source assets continue appearing. Investigate a different mechanism when the model inventory is unchanged but cache or writable-layer growth persists, or when derived files re-enter discovery. This test answers why storage grew without turning an explanation into a destructive cleanup procedure.
Recommended products
Tech & AI HUB
More to Read
Open Models Are Catching Frontier AI—Is 2026 the Year Local AI Becomes Good Enough?
Open models are getting good enough for more local AI workloads, while frontier cloud models remain useful for the hardest reasoning and agent tasks.
NVIDIA PAIR Turns Your Home Network Into a Local AI Cluster—Do You Still Need One Big GPU Server?
NVIDIA PAIR spreads local AI requests across multiple PCs, making compute more elastic while one home server can keep data and state persistent.
Why Does Immich Feel Faster on LAN Than on Remote Connections?
LAN requests usually take a shorter, lower-latency path. Remote access adds WAN capacity limits and may add DNS, TLS, proxy, VPN, or relay hops.
