Why an Immich Library Needs More Space Than Its Originals

An Immich installation needs room for more than the photos and videos being imported. It also stores generated images, sometimes separate video versions, database information, and database dumps. For a self-hosted photo library, the useful question is not simply whether the originals fit: it is whether the home server can keep growing while still serving the library and protecting it.

This is a capacity-planning explainer, not a migration or deletion procedure. Folder examples follow the current official Docker documentation; custom installations and older releases can use different mappings. Reading the plan requires no special access, but inspecting actual host storage requires permission to view the relevant filesystems. Changing instance-wide image settings requires an administrator.

Distinguish the archive from its browsing copies

Originals and generated files have different jobs. An original preserves the uploaded asset. A thumbnail makes a grid of photographs practical to browse; a larger preview supports viewing an individual photograph. A transcoded video can improve playback compatibility without replacing the original. These are not independent backup copies.

The official storage inventory identifies the principal file groups:

• upload/ contains uploaded originals in the default arrangement.
• library/ is used when the storage template engine organizes originals; do not assume every installation stores them there.
• thumbs/ contains generated preview images, including face thumbnails.
• encoded-video/ holds separate encoded video assets where needed.
• profile/ holds profile images, while backups/ contains database dumps.

The PostgreSQL data location is another part of the installation. Counting only the directory that contains the original photographs misses these other consumers.

Image previews trade storage for a browsing experience

Immich exposes separate thumbnail and preview settings. Its system-settings documentation explains that higher resolutions and quality can preserve more detail but require larger generated files and more encoding work. Previews are also used for machine learning, so treating their quality as a purely cosmetic preference misses a dependency.

That makes a universal overhead percentage misleading. A collection of many small images and a collection of fewer large originals need not have the same ratio of generated files to original bytes. Image settings and library composition matter. The sensible planning unit is a representative import processed with the intended settings, not an arbitrary multiplier taken from another installation.

Small timeline images and larger previews live together under thumbs/. The custom-location guide explicitly says these cannot be separated into different storage locations. Budget that folder as a shared workload rather than assuming each viewing mode can get its own disk.

Video can add another file rather than shrink the first

A smaller playback version does not mean the original video has become smaller on disk. The Immich FAQ distinguishes preserved originals from the additional transcoded versions used for compatibility and performance.

Whether a separate version is needed depends on the policy and the source asset. Current documentation describes decisions involving codecs, pixel format, HDR, container format, bitrate, and resolution. Not every video necessarily gets a second file. Conversely, choosing never to transcode can leave some browsers or devices unable to play a source format, or require more playback bandwidth.

The capacity decision therefore starts with the devices that will view the library. Saving space by eliminating a useful derivative can transfer the problem to playback. This article does not recommend disabling transcoding or manually removing encoded files as a shortcut.

Separate disks create separate capacity limits

Immich supports placing generated files in custom locations using Docker mounts. This can be useful when an archive belongs on larger storage while frequently accessed generated images belong elsewhere. It also turns one apparent storage pool into several failure points.

The official custom-location guide warns that Immich's storage metrics track the filesystem at UPLOAD_LOCATION. A smaller filesystem holding an overridden thumbnails directory can run out even while the main archive location has plenty of space. Host-level monitoring needs to cover every filesystem involved, including the database location, rather than relying on one application capacity display.

A split layout is not automatically a performance improvement. Its benefit depends on the workload and storage available. It also requires backup paths to follow the actual placement of important files. Treat moving directories as a separate, backed-up maintenance task; changing a path variable alone is not a completed migration.

Backup capacity is a separate commitment

Immich's automatic database dumps contain metadata, not a copy of the photo and video collection. The database and original assets must both be protected. A generated preview beside an original does not protect either from losing the disk that holds them.

The project recommends backing up the entire upload location. It also documents a narrower backup set with the critical original-content folders, provided thumbnail generation and video transcoding are rerun after restoration. That is a recovery-time tradeoff, not permission to delete generated files from a running instance. External-library originals and relocated folders need coverage at their real locations.

Make a capacity decision from a finished sample

A useful estimate records original bytes, generated-image bytes, encoded-video bytes, database storage, retained dumps, and separate backup storage after representative processing finishes. Include both photographs and the kinds of video the household actually records. Leave headroom for future uploads and maintenance rather than sizing disks to the first completed import.

The expected result is a per-filesystem capacity plan with an explicit backup budget, not a claim that every library grows by the same percentage. If observed usage differs from expectations, first distinguish pending processing, a custom mount, and a different transcode policy. Keep the existing files intact while investigating. The archive, the browsing experience, and recovery all consume resources, but they should never be mistaken for the same thing.