Immich vs PhotoPrism: Choosing a Self-Hosted Photo Library

Every few months someone asks me which self-hosted photo tool to run, and I’ve given a different answer at different points over the past three years, because both major contenders have changed enough to flip my recommendation twice. Here’s where things actually stand and why I ended up settling on the one I run today. The same question comes up for documentation, in Wiki.js vs BookStack: Choosing a Self-Hosted Wiki.

Why leave Google Photos at all

Google Photos is genuinely good software, which is exactly the problem — it’s good enough that leaving requires a real reason, and “the free unlimited tier ended a few years ago” is reason enough for most people once they check what they’re actually paying per month for storage they could own outright on a NAS that costs less than eighteen months of that subscription. The other reason, less often stated but more important to me, is that your photo library is the single most personally revealing dataset you generate — location history, faces, home interiors, children — and running the tool that indexes all of it on infrastructure you control is a meaningfully different privacy posture than trusting it to any company’s ongoing business model.

Immich and PhotoPrism are the two mature options that have emerged to fill that gap, and they’ve taken genuinely different paths to get there, shaped by different founding assumptions about what a self-hosted photo library is actually for.

Immich: the Google Photos replacement built to feel like Google Photos

Immich is the newer of the two but has had the faster-moving development and the larger community by a wide margin. Its whole design goal is matching the Google Photos mobile experience closely enough that non-technical family members don’t notice a difference: automatic background upload from a phone the moment you take a photo, a timeline view, face recognition and grouping, and — critically — a genuinely good mobile app for both iOS and Android that handles background sync reliably.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

services:
  immich-server:
    image: ghcr.io/immich-app/immich-server:release
    container_name: immich-server
    restart: unless-stopped
    environment:
      DB_HOSTNAME: immich-db
      DB_USERNAME: immich
      DB_PASSWORD: ${IMMICH_DB_PASSWORD}
      DB_DATABASE_NAME: immich
      REDIS_HOSTNAME: immich-redis
    volumes:
      - /mnt/photos:/usr/src/app/upload
    ports:
      - "127.0.0.1:2283:2283"
    depends_on:
      - immich-db
      - immich-redis

  immich-redis:
    image: redis:7-alpine
    container_name: immich-redis
    restart: unless-stopped

  immich-db:
    image: tensorchord/pgvecto-rs:pg16-v0.2.0
    container_name: immich-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: immich
      POSTGRES_USER: immich
      POSTGRES_PASSWORD: ${IMMICH_DB_PASSWORD}
    volumes:
      - immich-db-data:/var/lib/postgresql/data

volumes:
  immich-db-data:

That pgvecto-rs Postgres image isn’t a typo — Immich’s facial recognition and “search by description” features rely on vector embeddings stored directly in Postgres, which is also why Immich benefits noticeably from a GPU for machine learning inference. I’ve written separately about running Immich’s machine learning on a spare GPU and the difference is substantial: face detection and smart search indexing on CPU alone on a large library can take days, while a modest GPU cuts that to hours.

PhotoPrism: the librarian’s tool

PhotoPrism took a different design philosophy from day one: rather than mirroring your phone’s photo app, it treats your existing folder structure as the source of truth and indexes it non-destructively, without ever moving or renaming your original files. If you already have a carefully organised folder hierarchy from years of manual curation, PhotoPrism respects it rather than importing everything into its own opaque storage scheme. Its tagging and search are strong — object detection, colour analysis, and a genuinely capable text search across metadata — but its mobile story is weaker: there’s no dedicated official app with the polish of Immich’s, and background auto-upload from a phone requires a third-party app or a manual sync workflow, which is the single biggest reason I’ve steered most people away from it for a household’s day-to-day phone photo backup.

Where they actually differ in practice

The honest comparison, after running both for extended periods: Immich wins decisively on mobile experience and is now the default recommendation for anyone whose primary use case is “replace Google Photos for a household that takes photos on phones.” PhotoPrism wins for anyone with a large existing archive of scanned or imported photos already organised into folders, who wants an indexer layered on top rather than a new home for the files.

Resource-wise, Immich is heavier — the machine learning features and vector search in Postgres want meaningfully more RAM and benefit from a GPU, where PhotoPrism runs comfortably on modest CPU-only hardware and still delivers useful tagging and search. If your hardware budget is a low-power NAS with no GPU and a modest CPU, that’s a real point in PhotoPrism’s favour worth weighing against Immich’s better mobile app.

Face recognition works well in both, though Immich’s clustering has felt more accurate in my own library over the past year of active development, likely reflecting how much faster that project has been shipping model updates.

Migration and running both side by side

Neither tool locks your original files away — both work from (or copy) your existing photo files rather than a proprietary container format, so trying one doesn’t burn a bridge to the other. I’d genuinely recommend standing up both against a copy of your library before committing, since the mobile-experience difference is something you only really feel once you’ve used the phone app for a week rather than read about it. Whichever loses gets torn down; nothing about the trial locks you into a migration you can’t reverse.

RAW support and storage layout

If you shoot RAW from a dedicated camera rather than exclusively on a phone, both tools generate JPEG previews from RAW files for fast browsing while retaining the original RAW alongside it, but the practical experience differs. Immich’s RAW handling has improved substantially over the last couple of years but still occasionally struggles with less common manufacturer RAW formats for preview generation, falling back to a generic icon rather than a thumbnail until you open the file directly. PhotoPrism’s longer history with photographer-focused workflows shows here — its RAW-to-JPEG preview pipeline via a bundled converter has felt more consistently reliable across a wider range of camera formats in my own testing.

Storage layout is the other practical difference. Immich organises uploaded files into its own internal folder structure once ingested, keyed by upload date and internal ID rather than your original folder names — this is invisible day to day through the app, but means the files on disk don’t mirror any structure you’d recognise if you went looking at the raw filesystem. PhotoPrism deliberately keeps your existing folder structure intact and indexes in place, which some people value specifically because it means the underlying files stay meaningful and portable even if you stopped using PhotoPrism entirely tomorrow.

Backups for either tool

Both tools need the same two things backed up: the actual photo/video files, and the database holding metadata, tags, albums and face-recognition data. Losing the files is obviously catastrophic and irreplaceable; losing just the database is recoverable but genuinely painful — you’d need to fully re-index and re-run machine learning against your entire library from scratch, potentially taking days for a large collection. I back up both using the same restic-based approach described in my 3-2-1 backup rule post, with the photo files themselves getting the more aggressive off-site replication schedule since they’re the part with zero possibility of regeneration. Whichever tool you run, test a full restore at least once — a photo library is exactly the kind of data where discovering a backup gap happens at the worst possible moment.

Troubleshooting

Immich machine learning jobs never finish or time out. Check whether the machine-learning container has GPU access configured correctly (nvidia-container-toolkit on the host, and the right runtime declared in compose) — without it, jobs fall back to CPU and a library of tens of thousands of photos can take genuinely multiple days to fully process on a modest CPU.

PhotoPrism doesn’t pick up new files added directly to the folder. PhotoPrism indexes on a schedule or on manual trigger, not via a filesystem watch by default in most deployments — trigger a re-index from the UI or configure the indexing interval shorter if you’re adding files outside its own upload flow.

Immich mobile app shows “backup incomplete” indefinitely. This is almost always a background app refresh permission issue on iOS specifically — iOS aggressively restricts background network activity for apps, and Immich’s background upload needs the relevant permission explicitly granted, not just the app installed.

Both tools show duplicate photos after a migration. This happens when the same files exist at multiple paths (an old backup folder plus a newer synced folder) and both get indexed independently. Deduplicate at the filesystem level before pointing either tool at your library — neither does true cross-path deduplication reliably during initial import.

Sharing albums with people outside your household

Both tools support generating shareable album links for people who don’t have an account on your instance — a grandparent who wants to see the same holiday photos without installing anything. Immich’s sharing flow is closer to what most people already expect from having used Google Photos sharing before: a link, optional expiry, optional password. PhotoPrism’s public sharing exists but is a less polished part of the product overall, reflecting its general focus on the owner-operator’s own workflow rather than a wider circle of viewers. If regularly sharing albums with non-technical relatives is part of your actual use case, count that as another point toward Immich rather than treating it as a minor feature checkbox.

Community and pace of development

Immich’s development pace over the past couple of years has been genuinely unusual for a self-hosted project — frequent releases, a large and active contributor base, and features shipping fast enough that a comparison written a year ago would already read as outdated in places. PhotoPrism’s development has been steadier and slower by comparison, which isn’t automatically a weakness; a slower-moving project around something as important as your photo archive has its own appeal, since fewer breaking changes and migrations means less risk of a database upgrade going wrong. Weigh which property you actually want from software holding this much irreplaceable personal data: the fastest-improving option, or the more conservatively paced one.

Which one to actually run

For a household replacing Google Photos with everyone on phones expecting automatic backup, Immich is the clear pick — the mobile app quality difference is the whole ballgame for getting non-technical family members to actually use a self-hosted replacement rather than quietly going back to a cloud service. For a photographer or archivist with a large existing folder structure who wants search and tagging layered on top without disturbing that structure, PhotoPrism’s respect for your existing organisation is the better fit. I run Immich for the household library and keep PhotoPrism around for an older archive I’ve never wanted to reorganise into Immich’s model — there’s no rule that says you need exactly one.