If the job is replacing Google Photos — automatic phone backup, a timeline, sharing with a partner — Immich wins, and in 2026 it isn't close. If the job is curating a large existing archive of folders that you want indexed but never touched, PhotoPrism remains the better librarian. Most people asking the question mean the first job, so the short answer is Immich; the rest of this is the reasoning and the cases where it flips.
Different centres of gravity
Immich is mobile-first: the native iOS and Android apps with reliable background upload are the product, and the server exists to receive. It's multi-user from the ground up — separate libraries, partner sharing, shared albums — which is exactly the Google Photos household model. PhotoPrism is folder-first: point it at a directory tree and it builds a searchable index over it, non-destructively, with your folder structure remaining the source of truth. Its mobile story is a PWA plus third-party apps, workable for browsing but not in the same league for backup, and multi-user is largely gated behind the paid Plus tier. The design split shows in storage too: Immich ingests uploads into its own directory layout (originals preserved bit-for-bit and exportable), while PhotoPrism leaves files exactly where and how it found them.
Feature comparison
| Immich | PhotoPrism | |
|---|---|---|
| Mobile apps | Native iOS/Android, background backup | PWA, third-party clients |
| ML search | CLIP smart search, faces, similarity | CLIP-style labels, faces, places |
| Multi-user | Free, unlimited, partner sharing | Limited free; full in paid Plus |
| External libraries | Yes, watches folders in place | Core design |
| Stack | Server + ML container + Postgres + Redis | Single container + MariaDB |
| Recommended RAM | 4–6GB with ML | 4GB+ |
| Funding | FUTO, salaried core team | Two-person team, memberships |
Both do RAW, both do video, both run their ML locally — nothing leaves your network in either case. Search quality on both is genuinely good; "red car at the beach" style queries work, and face recognition is accurate enough to be useful for both once trained.
Performance on real libraries
The number that surprises people is the initial ML pass. On CPU, budget roughly 0.5–2 seconds per photo for smart search embeddings plus face detection — a 50,000-photo library means somewhere between 8 and 24 hours of background crunching on a typical mini PC (an estimate; codec mix and resolution move it a lot). Both projects let you throw a GPU at it, which collapses that to under an hour, but it's a one-time cost either way: day-to-day incremental imports are trivial. After indexing, both are snappy at six-figure photo counts; Immich's timeline scrolling on mobile is the standout, and PhotoPrism's density of filtering options is the power-user draw. Disk overhead for thumbnails and previews runs 10–20% of library size on both — plan for it. Both also deduplicate on import, which matters more than it sounds once you feed them a decade of Takeout archives full of repeats.
Hardware sizing note: Immich's Postgres does vector search (via its required extensions), and the docker-compose it ships pins specific database images. Don't fold it into a shared Postgres; run its stack as shipped, per the Immich docs.
Sustainability: the question that used to decide this
For years the honest knock on Immich was velocity without stability — breaking changes arriving mid-month with a "not ready for your only copy" warning on the README. That era ended: FUTO took stewardship in 2024, put the core team on salary, and the project shipped its stable release in late 2025 with aligned server/mobile versioning and a real deprecation policy. It's now among the most active projects in self-hosting by contributor count.
PhotoPrism's model is the opposite shape and also credible: a small team funded by memberships since 2018, deliberate release cadence, very few surprises. The risk profiles differ — big-sponsor dependency versus small-team dependency — but neither reads as abandonment-prone in 2026, per each project's public activity and the PhotoPrism docs roadmap. I stopped weighting this factor heavily; both have earned trust.
Migration and coexistence
Coming from Google Photos, the community tool immich-go ingests Takeout archives directly, preserving albums and metadata sidecars — the full worked process is in leaving Google Photos for Immich, and the broader option space in the Google Photos alternatives page. Coming from a curated folder archive into Immich, use its external library feature rather than importing: your folders stay authoritative and Immich indexes in place, which is the PhotoPrism-ish workflow inside Immich.
Running both against the same read-only archive is legitimate and I did it for six months while deciding: Immich for phones and family, PhotoPrism interrogating the deep archive. The cost is a second indexing pass and a few GB of duplicate thumbnails, not data risk — neither writes to originals unless asked.
The 2026 verdict
Immich, for the central use case, without much hesitation: the mobile backup pipeline is the whole reason to leave Google Photos, and it's the thing Immich does that PhotoPrism structurally doesn't. Pick PhotoPrism when there are no phones in the equation — a scanned-slides archive, a photographer's directory tree, a NAS full of two decades of folders that must remain exactly as they are — or when its filtering-first UI matches how you actually work. And whichever you choose, the photos live on your disk in original form, so this is a decision you can revise in an afternoon, not a platform you're marrying.