Tune Immich on a small home server by protecting upload and database responsiveness first, then limiting or scheduling thumbnail, video, and machine-learning work according to measured CPU, memory, and storage pressure.
The relevant workload is not an idle dashboard; it is the evening when several phones upload photos and videos while backups, searches, and derived-media jobs compete. Capture that peak, change one concurrency or schedule control at a time, and preserve originals plus database backups. A slower queue is acceptable; failed uploads, swapping, or an unresponsive database are not.
Measure the Busiest Family Upload Before Tuning
Create a representative batch containing phone photos, short videos, and one larger clip. Record upload completion time, job queue depth, CPU, memory, swap, disk latency, free space, and network throughput from start until the queue returns to zero. This baseline identifies the resource that actually saturates.
A small-server discussion about Immich machine learning shows how hardware advice varies with library size, model choice, and whether processing can run later. Use that workload-dependent comparison to avoid buying or tuning from idle utilization.
Pass means uploads remain responsive and the backlog drains within your acceptable window. If memory swaps or containers restart, reduce concurrency first. If CPU is full but interaction stays responsive, schedule heavy work. If storage latency rises across services, protect the active data path before changing models.
Bound Concurrent Jobs and Schedule Heavy Work
Reduce concurrency for the measured heavy queue rather than globally starving every worker. Video transcoding and machine learning commonly dominate different resources, while metadata extraction and thumbnails affect perceived readiness. Change one queue, rerun the same batch, and compare both responsiveness and drain time.
Schedule large library scans, backups, and optional reprocessing outside the family upload window. Do not overlap a storage snapshot, database maintenance, and video transcode on a server with one slow disk. A pass lowers peak contention without leaving an ever-growing queue.
Keep retry limits and logs visible while tuning. If jobs fail, restore the previous setting and address the error instead of reducing workers until failure becomes less noticeable. The goal is bounded work, not hidden work.
Keep Active State Fast and Originals Protected
Place the database and frequently written derived data on low-latency reliable storage when possible, while choosing the originals tier for capacity, durability, and backup design. Avoid moving the raw database directory to a casual network share simply to free local space.
An independent Immich self-hosting guide illustrates the broader storage, access, and remote-use decisions around a household photo service. Use it as architecture context, then validate your own paths and failure behavior.
The ZimaSpace family photo backup guide helps keep tuning subordinate to recoverability. Faster processing does not compensate for an untested database and original-file backup.
Retest the Family Workflow and Set a Stop Boundary
Repeat the identical batch while another family member browses, searches, and downloads an original. Pass requires successful uploads, usable interaction, no swap spiral or container restart, and a queue that drains within the planned off-peak window.
Restart the server, confirm mounts and limits persist, then test one phone's background upload away from the local network. Track a week of peak rather than average use. Only consider new hardware when the same named resource repeatedly violates the target after safe tuning.
Roll back a limit if queues never clear or derived assets remain missing. Stop adding simultaneous jobs when free space falls below the measured burst requirement. Escalate with the fixed test batch, charts for CPU, memory and storage latency, queue names, and before-and-after settings rather than a single utilization screenshot.
Support & Tips
More to Read

How to Optimize Immich Database Connections for Concurrent Containers
Do not raise max_connections first. Measure Immich sessions, total every container's demand, preserve admin headroom, and tune only the proven bottleneck.

How to Prevent Duplicate Jobs or Imports in Immich
Separate repeated jobs from duplicate assets. Use one canonical ingestion path, control retries and path changes, then test re-entry on a small cohort.

How to Repair Immich After Its Database Volume Fills Up
Never delete PostgreSQL WAL to free space. Stop Immich writes, preserve database state, add safe capacity, recover PostgreSQL, then prevent recurrence.

