Can Immich Keep Photo Search Usable During Large Mobile Imports?
Yes, Immich can keep existing photo search usable during imports when shared resources retain headroom, although newly uploaded photos may become searchable later.
A household imports years of phone pictures while someone searches for an older birthday album. Returning that known album promptly and finding every photograph uploaded this minute are different promises. Evaluate both separately, because background processing can fall behind without taking established search offline, while resource contention can make even previously indexed results slow.
Existing Search and New Coverage Are Different Promises
Existing indexed assets already have the information required by their supported search route. Newly accepted uploads may still need metadata extraction, display preparation, and relevant indexing jobs. A successful upload therefore establishes neither immediate semantic-search coverage nor a promise that every search feature has finished processing the asset.
Firsthand large-library reports describe very different import experiences across small boards and larger machines, including installations that remained usable while processing continued. Those accounts demonstrate variability rather than a minimum RAM rule. Media mix, enabled jobs, concurrent services, and acceptable waiting time matter alongside the number of photographs.
The conditional answer is yes when a known query still returns its expected results within the household tolerance and new assets continue progressing. It becomes no for freshness if indexing stops advancing, even when old searches work. Conversely, a growing queue alone does not prove the interactive service has become unavailable.
More Import Work Can Consume Interactive Capacity
Uploads, derivative generation, database operations, and inference consume overlapping resources. Increasing background concurrency can finish more jobs per minute until a shared dependency saturates; beyond that point, extra waiting may hurt interactive requests. A higher ingestion rate and a slower search experience can therefore occur together on the same host.
A version-specific importer report described job-pause controls that did not cover every active queue with immich-go 0.28.0 and Immich 2.3.1. The reporter did not establish that this caused the observed connection errors. Its useful lesson is narrower: a control label is not evidence that all background work is actually paused.
Scheduling less background work during family use trades completion time for potential interactive headroom; it does not create capacity. Observe the active queues and user-visible timings after a supported change. If search remains slow while those queues are idle, investigate the remaining query path instead of attributing every delay to import concurrency.
ML Acceleration Cannot Protect Every Dependency
Moving inference to an accelerator or another host changes one service boundary. It does not automatically accelerate PostgreSQL, original-media reads, thumbnail generation, or client rendering. A fast machine-learning stage can coexist with a congested database or storage pool, and a remote service introduces its own network and availability dependency.
An OCR resource report for Immich 2.2.0 described rapid face and smart-search processing but much heavier OCR behavior with a particular model and environment. This is a historical incident, not a current universal defect. It illustrates why the speed or memory demand of one ML job cannot stand in for every enabled job.
The availability claim fails when required services restart under memory pressure, queries time out, storage runs out of writable space, or a necessary network path becomes unreachable. Faster inference alone cannot resolve these boundaries. Keep privacy separate as well: local processing does not compensate for overly broad accounts, exposed endpoints, or unsuitable backup handling.
Define What Usable Means for Your Household
Choose a small set of old, known-result queries and a new import sample with recognizable subjects. Record query completion times, errors, and the delay until the sample becomes searchable through the intended feature. Repeat during a quiet period and a representative import without changing the account, client, or network route.
Self-hosting shifts household operating responsibilities toward the server owner, including service availability, access, and backup decisions. That distinction matters when defining usable search: occasional indexing delay may be acceptable, but losing access during every nightly import may not be. A cloud comparison supplies that responsibility context, not a performance guarantee for Immich.
Set separate acceptance limits for established search latency and new-photo readiness, then watch whether the backlog drains after uploads stop. Passing both supports continued use under the tested workload only. If either fails, the next decision is which dependency or scheduling overlap violates that limit—not an assumption that all large libraries need the same hardware.
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.
