Plan a 10TB+ Immich library around the bottleneck, not the drive size.
A large Immich library stresses original media storage, generated thumbnails and transcoded video, Postgres latency, background job concurrency, machine learning throughput and backup recovery time. Buying larger disks solves only one of those constraints.
What "large" means here
This guide uses 10TB+ as a planning scenario because storage layout, recovery time and import throughput usually matter more at that size. It is not an official Immich limit, and it is not a benchmark from SelfHostPlanner testing.
Immich's official baseline is still the starting point: 6GB minimum RAM, 8GB recommended RAM, 2 CPU cores minimum and 4 recommended cores. Those numbers do not mean every 10TB library needs a workstation; they mean the first decision is whether the workload is mostly serving photos, processing a first import, transcoding video, or running machine learning jobs.
Architecture priorities
| Component | Large-library rule | Why it matters |
|---|---|---|
| Postgres | Use local SSD for DB_DATA_LOCATION. | Immich says database performance and a stable connection are critical, and warns not to place Postgres on a network share. |
| Original media | Use a Unix-compatible filesystem with permissions support. | Immich's requirements call out filesystem ownership and permissions. |
| Generated media | Reserve 10-20% above original library size. | Immich documents thumbnails and transcoded video as an average 10-20% library-size increase. |
| Jobs | Throttle or distribute workers only after the queue shows pressure. | Uploads trigger metadata, thumbnails, machine learning and other background jobs. |
| Machine learning | Keep local unless CPU/RAM/acceleration is the measured bottleneck. | Remote ML helps specific workloads, but adds a service boundary and version-management work. |
Import strategy
- Start with a representative batch. Import a small folder with common phone photos, RAW files and videos. Watch CPU, memory, disk I/O and the Immich Jobs page before committing the full archive.
- Separate ingest from normal use. Large imports can fill queues with metadata extraction, thumbnails, video encoding and machine learning jobs. Plan a window where slow search or delayed thumbnails will not be confused with a broken deployment.
- Use external libraries deliberately. External libraries let Immich scan media already stored outside Immich. They are useful for testing an existing archive layout, but metadata added inside Immich may not persist back to the source file, and deleted external files can move to trash on rescan.
- Do not raise every concurrency slider. Immich notes that higher job concurrency improves throughput rather than search latency. On normal machines, even 2 or 3 concurrent jobs can max the CPU, and HDD latency can become the limiting factor.
- Document rollback points. Before changing storage templates, external library paths, ML settings or worker splits, record current settings and confirm the database backup and media backup are restorable.
When to split workers
Immich supports splitting the immich-server container so one copy handles API traffic while another handles microservice jobs. Treat this as an operational scaling tool, not a default install pattern. It makes sense when the web UI is affected by heavy background work and the host has enough CPU, memory and storage I/O to benefit from separation.
A conservative sequence is: keep the default workers, lower unnecessary job concurrency during imports, move machine learning to another host if ML is the bottleneck, then split API and microservice workers if background jobs still interfere with interactive use.
10TB capacity worksheet
| Input | Planning assumption | Adjust before buying |
|---|---|---|
| Original library | 10TB today | Use the actual measured folder size, not disk label size. |
| Generated media | +1TB to +2TB | Use Immich's documented 10-20% range. |
| Free-space headroom | 20-30% | Higher if imports arrive in bursts or drives are slow to replace. |
| Independent backup | At least one restorable copy | Mirror/RAID is not a backup; test restore time, not just backup success. |
| Database placement | Small local SSD allocation | Immich says the database is typically 1-3GB, but latency matters more than size. |
Operational checks
- After every large import, confirm the Jobs page drains rather than repeatedly failing the same job type.
- Keep enough SSD space for Postgres, Redis data, model cache and Docker overhead, not just the media mount.
- Watch whether video transcoding, Smart Search or Face Detection dominates the queue before changing hardware.
- Use the calculator for primary storage, generated-media overhead, backup copies and headroom; use this guide for placement and workflow decisions.
- Write down which settings are planning assumptions: growth rate, generated-media percentage, concurrency, backup copy count and restore-time target.
Commercial and source note
This guide does not recommend a paid NAS, mini PC, disk vendor or cloud server. It also does not claim that SelfHostPlanner tested a 10TB Immich deployment. The purpose is to turn official Immich constraints into a purchase and implementation checklist.
Estimate storage, backup copies and local-versus-VPS cost for your library →
规划 10TB+ Immich 图库时，先看瓶颈，不要只看硬盘容量。
大型 Immich 图库会同时考验原始媒体存储、缩略图和转码视频、Postgres 延迟、后台任务并发、机器学习吞吐量以及备份恢复时间。只买更大的硬盘只能解决其中一个约束。
这里的“大图库”是什么意思
本文把 10TB+ 当作规划场景，因为到这个规模时，存储布局、恢复时间和导入吞吐量通常更重要。它不是 Immich 官方限制，也不是 SelfHostPlanner 的性能测试结论。
Immich 官方基线仍然是起点：最低 6GB 内存、推荐 8GB 内存、最低 2 个 CPU 核心、推荐 4 个核心。这并不表示每个 10TB 图库都需要工作站；它表示你应该先判断工作负载主要是浏览照片、首次导入、视频转码，还是机器学习任务。
架构优先级
| 组件 | 大型图库规则 | 原因 |
|---|---|---|
| Postgres | DB_DATA_LOCATION 使用本地 SSD。 | Immich 说明数据库性能和稳定连接很关键，并提醒不要把 Postgres 放在网络共享上。 |
| 原始媒体 | 使用支持权限的类 Unix 文件系统。 | Immich 要求文件系统支持所有权和权限。 |
| 生成媒体 | 在原始图库上方预留 10-20%。 | Immich 文档说明缩略图和转码视频平均会增加 10-20% 图库体积。 |
| 任务 | 只有队列显示压力后，才限速或拆分 worker。 | 上传会触发元数据、缩略图、机器学习和其他后台任务。 |
| 机器学习 | 除非 CPU、内存或加速硬件是已测量瓶颈，否则先保留本地。 | 远程 ML 能解决特定负载，但会增加服务边界和版本管理工作。 |
导入策略
- 先导入有代表性的小批量。 选择包含常见手机照片、RAW 文件和视频的文件夹。完整导入前，观察 CPU、内存、磁盘 I/O 和 Immich Jobs 页面。
- 把导入和日常使用分开。 大导入会让队列充满元数据提取、缩略图、视频编码和机器学习任务。安排一个窗口，避免把搜索变慢或缩略图延迟误判为部署损坏。
- 谨慎使用外部图库。 外部图库可以让 Immich 扫描已经存放在 Immich 之外的媒体。它适合测试既有归档结构，但在 Immich 内添加的元数据可能不会写回源文件，外部文件删除后重新扫描也可能进入回收站。
- 不要把所有并发都调高。 Immich 说明更高并发提升的是吞吐量，不是搜索延迟。在普通机器上，2 或 3 个并发任务就可能打满 CPU；使用 HDD 时，延迟也可能很快成为限制。
- 记录回滚点。 修改存储模板、外部图库路径、ML 设置或 worker 拆分前，记录当前设置，并确认数据库备份和媒体备份可以恢复。
什么时候拆分 worker
Immich 支持拆分 immich-server 容器，让一个副本处理 API 流量，另一个处理 microservices 任务。应把它视为运维扩展工具，而不是默认安装方式。只有当后台任务影响网页交互，并且主机有足够 CPU、内存和存储 I/O 时，拆分才有意义。
保守顺序是：先保留默认 worker；导入期间降低不必要的任务并发；如果 ML 是瓶颈，再把机器学习移到另一台主机；如果后台任务仍然影响交互使用，再拆分 API 和 microservice worker。
10TB 容量工作表
| 输入 | 规划假设 | 购买前调整 |
|---|---|---|
| 原始图库 | 当前 10TB | 使用实际测量的文件夹大小，而不是硬盘标称容量。 |
| 生成媒体 | +1TB 到 +2TB | 使用 Immich 文档中的 10-20% 范围。 |
| 空闲余量 | 20-30% | 如果导入是批量到达，或更换硬盘很慢，应提高余量。 |
| 独立备份 | 至少一份可恢复副本 | 镜像/RAID 不是备份；要测试恢复时间，而不只是备份成功。 |
| 数据库位置 | 小容量本地 SSD | Immich 说明数据库通常为 1-3GB，但延迟比容量更重要。 |
运维检查
- 每次大型导入后，确认 Jobs 页面会逐步清空，而不是同一类任务反复失败。
- 为 Postgres、Redis 数据、模型缓存和 Docker 开销保留足够 SSD 空间，不要只计算媒体挂载点。
- 在更换硬件前，先观察队列主要被视频转码、Smart Search 还是 Face Detection 占用。
- 用计算器估算主存储、生成媒体开销、备份副本和余量；用本指南决定放置位置和流程。
- 写清哪些属于规划假设：增长率、生成媒体比例、并发数、备份副本数和恢复时间目标。
商业与来源说明
本文不推荐付费 NAS、小主机、硬盘厂商或云服务器，也不声称 SelfHostPlanner 测试过 10TB Immich 部署。它的目标是把 Immich 官方约束转成购买和实施清单。