Should You Put Immich Metadata on SSD and Bulk Data on HDD?
Yes, an Immich deployment often benefits from keeping the database and latency-sensitive generated data on SSD while storing large original photo and video files on HDD, especially when the library is much larger than the app state. The split is useful only when the paths, free-space margins, backups, and recovery steps remain clear.
The decision is not “metadata fast, media slow.” Immich touches several storage roles differently: PostgreSQL handles many small state operations; thumbnails and previews are read frequently while browsing; encoded video can be large; originals favor capacity and durability. Measure those roles separately before moving anything.
Separate Hot Small-I/O State From Capacity-Oriented Media
Inventory the PostgreSQL data, thumbnails, previews, encoded video, model cache, uploaded originals, external libraries, and backup copies. Record current size, growth, read/write frequency, rebuild cost, and whether each role must survive a restore. This prevents a generic “metadata” folder label from hiding several very different workloads.
The ZimaSpace storage framework for placing media metadata and active cache makes the useful distinction: databases and indexes benefit from low-latency storage, while bulk source media can remain on capacity storage when its access pattern does not require the same IOPS. If your current HDD shows low latency during searches, timeline browsing, and background jobs, moving every derivative to SSD may provide little user-visible gain. Keep the current layout until a controlled comparison shows that the active storage path is actually waiting.
Put PostgreSQL and Frequently Read Derivatives on SSD When They Are the Wait
PostgreSQL and thumbnail-heavy browsing create many small reads and writes that can feel slow on a busy mechanical disk, especially while imports or backups use the same device.
For current Immich layouts, keep the database on local low-latency storage and move supported generated-data paths deliberately rather than inventing arbitrary nested mounts.
The storage mechanism is well understood outside Immich: PostgreSQL storage tuning benefits from much cheaper random access than spinning disks. That does not guarantee a visible Immich gain, but it explains why database and index work are strong SSD candidates when device latency is the measured wait.
Measure the improvement with the same album, search, and import sample before and after. If database latency falls but the user-visible request is still waiting on network transfer, image decoding, or machine learning, stop attributing the remaining delay to the HDD.
Keep Originals on HDD When Capacity and Protection Matter More Than Random I/O
Original photos and videos are usually the largest storage class and are often read as whole files rather than as tiny random database pages. Large HDD pools can therefore be a sensible home for originals when they provide the required reliability, throughput, and backup capacity. The HDD tier still needs free space and healthy latency during simultaneous import and browse workloads.
A long-running Immich storage discussion about separating thumbnails from media reflects the same operational desire: generated browsing assets and bulk originals have different access priorities. It does not prove every installation needs two physical devices; the gain depends on where requests currently wait.
Do not put irreplaceable originals on HDD simply because it is cheaper and then treat RAID as the backup. Keep a second copy and an off-host or offline copy according to the household protection goal. Storage tiering changes performance and cost; it does not reduce the consequence of losing the only copy of the family library.
Migrate One Storage Role at a Time and Reboot-Test the Mounts
Before moving a path, capture a database-consistent backup and record the current host-to-container mount map. Move one role, start the stack, verify old and new assets, run a search, play a video, upload a disposable file, and confirm the new writes land on the intended device. Do not move database, thumbnails, originals, and backup destinations in one change.
Reboot the host rather than only recreating containers. A passing split layout brings both SSD and HDD mounts online before Immich writes, preserves users and relationships, reads sampled originals, and keeps free-space monitoring on both tiers. An empty replacement directory at an expected mount point is a stop condition. Keep the split when the measured bottleneck improves and the recovery map stays understandable. Roll back if the layout introduces stale paths, missing assets, permission drift, or a backup process that protects only one tier. The best storage design is the fastest one you can still restore correctly.
Recommended products
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.
