How Much Storage Overhead Does Immich Add Beyond Source Data?
Immich adds no universal storage percentage; overhead depends mainly on asset count, video mix, derivative settings, database growth, and retained backups.
A one-terabyte family library dominated by photos will not resemble one dominated by long phone videos. Plan storage by measuring each generated class after a representative import, then reserve separate room for growth, temporary work, and recovery copies.
Derived Media Usually Forms the Largest Visible Overhead
Immich prepares smaller images for timelines and viewers, and it may create encoded versions of videos for compatible playback. These outputs scale with asset count, resolution choices, quality settings, and video duration or codec mix. They are additional to the original files even when users never download them directly.
A community measurement of a 772 GiB external library reported about 18 GiB of thumbnails and 65 GiB of encoded video. That roughly 83 GiB observation is useful as a worked example, not a planning ratio, because another library’s photo-to-video mix and settings can change both components substantially.
Record thumbnail and encoded-video directories after importing a representative slice containing the household’s real photos, RAW files, short clips, and long videos. Divide each derivative class by asset count and source bytes separately. Asset-based and byte-based ratios answer different growth questions.
Database and Search State Scale With Relationships
Database overhead comes from asset records, users, albums, metadata, faces, search representations, indexes, and job state. A tiny image and a large video may create similar counts of some records despite very different source sizes. This makes database growth more closely related to entities and enabled features than original terabytes.
The ZimaSpace Immich backup article separates essential originals and database state from derived paths that may be rebuilt. That separation matters when forecasting because deleting derivatives can reclaim space temporarily, while losing the database changes relationships that thumbnails cannot reconstruct.
Capture database size before and after importing a known cohort, then note which processing features completed. Repeat after face and search work finishes. Do not extrapolate from an unfinished queue, because the apparent overhead per asset will rise as additional representations and relationships are written.
Backups and Temporary Work Change the Capacity Floor
A running total excludes space needed while backups are created, databases are dumped, imports are staged, or derivatives are replaced. During an upgrade or regeneration, old and new artifacts may coexist. A disk sized exactly to steady-state usage can therefore fail during ordinary maintenance even when annual media growth is modest.
A storage-planning essay describes Immich filling a previously spare SSD through originals, thumbnails, metadata, and machine-learning work. Its broader lesson is that application growth and recovery copies compete with operational headroom, so a free-space figure must cover the busiest maintenance condition rather than today’s idle state.
Keep backup retention as a separate line item because off-host copies protect against a different failure. Also reserve an observed working margin from the largest import, re-encode, or upgrade test. More unused space is not automatically better, but zero measured peak margin makes capacity failure predictable.
Build a Library-Specific Overhead Worksheet
Create rows for originals, thumbnails and previews, encoded video, database, machine-learning artifacts, local backup dumps, and temporary peak space. Measure an empty baseline, then import a representative cohort. Wait for queues to drain and record every row again before calculating differences.
A practitioner discussion about SSD and HDD placement distinguishes latency-sensitive generated data from bulk originals. For capacity work, that distinction keeps fast-tier overhead visible even when originals live elsewhere; otherwise the large NAS total can hide a nearly full application SSD.
Repeat the cohort once to obtain a range rather than one ratio. Forecast each row with its appropriate driver: asset count, video bytes or duration, user and relationship growth, retention count, or peak maintenance work. Add planned source growth only after derived and recovery needs are visible separately.
Recommended products
Tech & AI HUB
More to Read
Why Does Immich Reprocess Existing Data After an Upgrade?
Immich may reprocess assets when an upgrade invalidates earlier derivatives, metadata, models, or job state; repeated endless work is a separate fault.
What Dependencies Most Often Set the Real Immich Performance Ceiling?
Immich is capped by the slowest dependency on each measured path, so upload, search, browsing, and playback can have different ceilings.
Immich Networking: How Discovery, DNS, and Routing Produce Reachability
Immich is reachable only when endpoint selection, DNS, routing, NAT or proxy handling, TLS, and application response form one valid path.
