During a large mobile-library import, Immich can accept assets faster than every search-related background job finishes, so search freshness may lag behind upload completion.
That lag is a scheduling problem only when the required jobs are waiting, running, or contending for shared resources; it is not automatically a search failure. The useful model is a pipeline: incoming assets create work, queues absorb bursts, workers consume those queues, and the database receives the results that later searches depend on.
Large Imports Create a Burst of Different Jobs
A mobile migration does more than copy bytes. Each accepted asset may create follow-on work for thumbnails, metadata, video handling, smart search, faces, or other enabled features. Because these jobs have different costs and dependencies, one import can create several backlogs with different drain rates.
The request for sequential jobs shows why users notice this behavior on constrained hosts: operators sometimes want heavy activities to run one at a time rather than overlap. That request is evidence of resource competition, not proof that sequential execution is best for every server.
Measure each queue by arrivals, completions, and failures instead of treating the total pending count as one workload. A large thumbnail backlog can delay other dependent work differently from a video-transcode backlog, and a queue that is steadily shrinking has a different meaning from one that repeatedly retries the same items.
Queue Priority Is Not the Same as Global Resource Control
A system can prioritize or pause selected work yet still have other job types active. This is why an import tool that reduces one class of background activity does not necessarily guarantee an idle CPU, quiet disks, or immediate search freshness. Scheduling policy and total resource consumption are related but not identical.
An immich-go release introduced paused background jobs during uploads to reduce conflicts. That behavior belongs to that importer and version, so it should not be generalized into a claim that every Immich mobile import automatically pauses the same work.
The practical boundary is observable progress. If uploads continue quickly while search-related queues remain intentionally paused, new assets will naturally become searchable later. If the queue is enabled but completions remain near zero, the question changes from scheduling policy to worker, resource, or asset-specific failure.
Concurrency Can Raise Throughput and Worsen Responsiveness
More concurrent workers can increase completed jobs per minute until a shared dependency saturates. After that point, extra parallelism may increase database waiting, storage latency, memory pressure, or context switching, so the system finishes background work faster on average while interactive requests develop longer tail latency.
A practitioner report about hung job queues describes a large library where reducing concurrency improved observed progress. It is a deployment-specific observation, but it demonstrates why concurrency should be tested as a workload variable rather than treated as a fixed indicator of server capability.
Use a known search for an already indexed album as the interactive control. If that query stays fast while new-photo coverage lags, the import is mainly a freshness problem. If even old queries slow down at the same time as CPU, storage, or database waiting rises, the scheduling window is consuming interactive headroom.
A Growing Queue Is Not Automatically a Fault
Backlog grows whenever work arrives faster than workers complete it. During an intentional historical import, that is expected for some period. The failure signal is not the peak queue length itself but the combination of stalled completion, repeated errors, or a backlog that fails to drain after arrivals stop.
Large-import discussions such as this 200,000-photo migration show how operators separate upload throughput from downstream processing. Community experience is useful for identifying what to measure, but it should not be converted into a universal time estimate for another library.
This mechanism stops explaining missing search results when the relevant job has completed and the same authorized user still cannot retrieve a known asset. At that point, inspect query relevance, filters, permissions, model behavior, or asset-specific processing rather than continuing to tune import concurrency.
Run a Two-Lane Scheduling Test
Create one fixed lane for old indexed content and one lane for a small new import. Before the import, record the response time of a known old search. During the import, record that same search, upload rate, pending and completed job counts, failures, CPU pressure, memory pressure, and storage latency at regular intervals.
Use the ZimaSpace analysis of the Immich data path to keep the transfer, processing, storage, and search stages distinct. A bottleneck is actionable only when it lines up with the stage whose service target is actually being missed.
Accept the schedule when old searches remain within your household tolerance, new-item queues continue completing, and the backlog drains after arrivals stop. Reduce or reschedule background concurrency only when the controlled test shows that the same shared resource is delaying both interactive use and queue progress.
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.

