Why Does Immich Reprocess Existing Data After an Upgrade?

Immich may reprocess existing assets when an upgrade changes the code, models, metadata, or derivative rules that define a current output.

The original photos have not changed, yet thumbnails, embeddings, faces, previews, or database records may no longer satisfy the new release. A bounded explanation follows which output was invalidated, which queue regenerates it, and whether the work completes once or repeats abnormally.

An Upgrade Can Change What Counts as a Current Output

Generated data is valid relative to the code, model, settings, and schema that produced it. When those expectations change, an existing thumbnail, embedding, face result, or metadata record may no longer be considered current. The asset remains the input even though only its derived representation needs work.

The ZimaSpace Immich backup article distinguishes essential originals and database state from derivatives that can be regenerated. That distinction explains why upgrade work can be large without implying original files were duplicated: the application may be rebuilding derived state around unchanged media.

Record which queues grow immediately after the upgrade and which directories or database sizes change. A thumbnail queue, machine-learning queue, and database migration represent different mechanisms. Calling all of them “reindexing” removes the evidence needed to estimate duration and resource pressure.

Dependency and Model Changes Can Invalidate Earlier Work

Immich spans application code, database behavior, queue coordination, machine-learning models, and media derivatives. An upgrade can alter interfaces or stored representation expectations between those components. A migration may update records quickly while background workers later regenerate expensive outputs for each affected asset.

A community discussion about preparing for Immich v3 highlights uncertainty over PostgreSQL, Redis, vector extensions, and application versions. The discussion does not prove any particular upgrade action, but it demonstrates that dependency compatibility is part of the state transition rather than an unrelated maintenance detail.

Preserve the pre-upgrade component versions and post-upgrade queue snapshot. If only one output class is scheduled and completes once, the behavior matches bounded regeneration. If components disagree on schema or extensions, repeated failures may appear before useful reprocessing can even begin.

Reprocessing Converts Compatibility Work Into Resource Pressure

A mature library can turn one changed rule into thousands of jobs. Thumbnail generation and media analysis consume CPU or accelerators, while reading originals and writing derivatives consume storage bandwidth. Database updates and queue activity continue simultaneously, so foreground browsing can slow even when reprocessing is healthy.

An Immich support thread reports high nightly CPU load and renewed thumbnail generation after an update on two servers. It is a field report rather than proof of intended behavior, but it supplies the exact observation pattern that should be checked against queue progress, logs, and completion recurrence.

Track items completed per minute, storage free space, device latency, memory pressure, and a fixed interactive request. Healthy reprocessing should reduce a finite backlog. Lowering concurrency can protect household use at the cost of duration; adding workers can worsen storage or database contention when those stages already set the ceiling.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Distinguish One-Time Regeneration From a Repeating Fault

Before the upgrade, save job counts, versions, free space, and several known asset identifiers. Afterward, sample the same identifiers and record which output is rebuilt, whether queue counts fall, and whether work returns after restart or the next scheduled maintenance window.

A thumbnail-recovery discussion reports missing images resolving after processing eventually finished, while manual refresh helped some individual assets. The mixed reports reinforce the boundary: elapsed time alone cannot classify behavior; finite queue progress differs from the same assets repeatedly failing or being re-enqueued.

Treat monotonically falling queues with stable outputs as one-time regeneration. Escalate when completed counts reset, identical assets recur, errors repeat, free space collapses, or no useful throughput appears. Preserve backups and logs before changing job state, because deleting evidence can obscure whether the upgrade or environment triggered the loop.