The short answer
A mini PC is a credible Google Photos replacement for a household library. On our Beelink EQi12, every component Immich depends on — PostgreSQL, Redis, NVMe storage and a gigabit uplink — measured far above what a family photo archive demands; the real constraints are 512 GB of shared boot storage and CPU-bound machine learning on first import, not raw database speed.
One honesty note before anything else: we have not run Immich end-to-end on this machine. What we have measured, on this exact unit, are the components Immich is built on. This page uses those numbers for what they are good at — capacity planning — and tells you where the first bottleneck will appear. If you want the raw benchmark data instead of the planning view, the EQi12 Docker component benchmark has it, and every figure is traceable to the public measurement data repository (CC BY 4.0).
Where this page fits among our other pages
We keep our comparison pages from stepping on each other, so here is the division of labor:
| Page | Answers this question |
|---|---|
| This page | Which self-hosted photo platform should I pick, and can this class of mini PC carry it? |
| EQi12 Docker component benchmark | What did Postgres, Redis and nginx actually score on this machine? |
| ZFS and RAID storage planning guide | How do I plan redundancy for a growing library? |
| Windows + Docker vs Proxmox on one mini PC | Which OS should host the containers? |
| Media storage calculator | How many GB will my specific camera and clip mix produce? |
What Immich actually needs from your hardware
Immich is not one program. A standard Docker Compose deployment runs several cooperating services, and each one leans on a different part of the machine:
| Immich service | What it does | What it stresses |
|---|---|---|
| Immich server | API, upload handling, thumbnail pipeline | CPU briefly, disk writes |
| PostgreSQL | Albums, users, EXIF metadata, asset index | Small, latency-sensitive transactions |
| Redis | Job queue, caching, session state | In-memory operations |
| Machine learning service | Face recognition, CLIP-based semantic search | CPU, sustained for hours on first import |
| Storage (filesystem or object store) | Originals, thumbs, encoded video | Sequential write on upload, random read on browse |
That architecture is why component benchmarks are more informative here than they might look. The database and the queue are the two pieces that make a photo library feel snappy when you scroll, and they are also the two pieces you cannot easily fix later by adding a USB drive.
The contenders: Immich, PhotoPrism, Nextcloud Memories
| Immich | PhotoPrism | Nextcloud Memories | |
|---|---|---|---|
| License | MIT-style open source | Fair-source (free self-host) | AGPL |
| Deployment | Docker Compose, multiple containers | Single heavy container | Nextcloud app |
| Mobile auto-upload | First-class, mature | Third-party workarounds | Via Nextcloud apps |
| Face recognition | Built-in ML service | Built-in, RAM-hungry | Requires extra setup |
| RAM appetite | Moderate | High (2-4 GB+ recommended) | Moderate + Nextcloud base |
| Timeline UX | Closest to Google Photos | Beautiful but its own idiom | Functional |
| Maturity | Very active, frequent releases | Mature, slower cadence | Tied to Nextcloud release cycle |
Feature tables like this one are everywhere, and honest ones mostly agree: Immich is the closest thing to “Google Photos, but on your disk.” What the tables cannot tell you is whether the mini PC you already own can carry it — which is the part we can measure.
The component evidence, clearly labeled
Everything in this table was measured on the same Beelink EQi12 (Intel i3-1215U, 6C/8T, 16 GB DDR4-3200, WD PC SN540 512 GB NVMe, firmware 33006000) running Docker on Windows. These are component benchmarks: the same class of work Immich’s database and cache perform, run standalone. They are not Immich scores.
| Component test | Result | What it means for a photo library |
|---|---|---|
| PostgreSQL 17, pgbench, 10 clients / 4 threads | 3,323 TPS, 0 failures | Metadata writes (upload, album edits) are a rounding error against this |
| PostgreSQL 17, pgbench, 30 clients / 6 threads | 4,385 TPS | Multi-user browsing headroom |
| Redis 8, 50 clients | SET 145,985 / GET 158,604 ops/s | Job queue dispatch will never be the bottleneck |
| Redis 8, 100 clients | SET 162,337 / GET 167,084 ops/s | Same conclusion under more contention |
| nginx container, 100 concurrent | 10,630 RPS, 0 errors | Static thumbnail serving has enormous headroom |
| NVMe sustained write | ~623 MiB/s | A 50 MB burst of photos lands in under a second |
| Gigabit Ethernet, measured end to end | 109-112 MiB/s | The network caps uploads before the server does |
Source: EQi12 Docker component benchmark and the storage and USB path comparison. Full CSVs live in the measurement data repository.
Where the bottleneck actually lands
Ranking the constraints for a household library on this hardware class, worst first:
1. Storage capacity, not storage speed. Our unit’s 512 GB NVMe is shared with the operating system, Docker and everything else. At a planning figure of 3-5 MB per JPEG, a 400 GB photo allocation is on the order of 80,000-130,000 pictures — a large family archive, but not bottomless, and phones shoot video too. The speed at 623 MiB/s is a non-issue; the ceiling is a capacity issue. Plan external or network storage from day one, and see the ZFS and RAID planning guide for redundancy patterns that survive a disk loss.
2. Machine learning on first import. Face recognition and semantic search are CPU work. A 6C/8T laptop-class CPU will chew through a tens-of-thousands-photo initial import over hours, not minutes, because ML inference is exactly the workload the i3-1215U’s efficiency cores were not designed for. This is normal for self-hosted photo platforms on mini PCs — but we have not measured Immich’s ML pipeline on this unit, so we give no duration numbers. After the initial pass, incremental work (a day’s photos) is small.
3. Upload bandwidth on first sync. The measured gigabit path moved 4 GiB at 109-112 MiB/s end to end. That works out to roughly 400 GB in about an hour on a LAN. Over a remote link, your internet upload speed replaces this number entirely — a 20 Mbps uplink needs about two days for the same 400 GB. The EQi12’s two Realtek ports measured 891-941 Mbps, so on the LAN side the server will not be the limiter.
4. RAM for the ML container. Immich’s machine learning service grows with concurrency. With 16 GB total and the OS taking its share, running the ML container plus the database plus a media server is comfortable; running ML plus several other heavy stacks invites swapping. Our 12.57-hour stability run with a mixed Docker stack held a minimum of 5,472 MB free memory with zero failures, which shows how much headroom a single-purpose deployment keeps.
The 24/7 power bill, from measured wall readings
Photo servers run all year, so wall power matters more than peak benchmarks. On the same EQi12, measured at the wall with a power meter:
| State | Measured |
|---|---|
| Docker stack idle (all services healthy) | 12 W |
| Windows idle | 14 W |
| Sustained full CPU load | 37 W |
| S3 sleep / shutdown | 1 W |
Source: EQi12 power consumption measurements.
The arithmetic is straightforward and labeled as derived: a photo server that spends nearly all its life in the 12-14 W idle band consumes roughly 8.7-10.2 kWh per month — around $1.50-1.75 per month at a typical US residential rate near $0.17/kWh. Even a heavy ML import evening (sustained 37 W for four hours) adds less than two cents. A mini PC photo library costs less to run per year than a single month of a cloud photo subscription.
Backup: the part Google Photos did for you
Self-hosting moves the durability problem onto your desk. Google Photos’ real product was not the app; it was three geographically separated copies of your memories. Replace it with:
- The server copy — originals on the NVMe (fast, small) or an external/network volume (large, expandable).
- A second local copy — nightly sync to an external SSD or a second machine. Our backup retention planner sizes the schedule; the backup and restore drill guide covers the Docker volume part.
- An off-site copy — cloud object storage or a drive at a relative’s house. Immutable or versioned, so ransomware or a deleted-library accident cannot take out all three copies.
One caution from our own testing: on this machine, three of four rear USB-A ports measured full SSD speed (~301-432 MiB/s) while one repeatedly negotiated near USB 2.0 class (~39-43 MiB/s). Verify a port before assigning it the nightly backup job — a bad port turns a 40-minute sync into an all-night one.
Reference card for citations
| Fact | Value | Condition |
|---|---|---|
| PostgreSQL 17 pgbench | 3,323-4,385 TPS | EQi12 i3-1215U, Docker, scale 10, 10-30 clients |
| Redis 8 throughput | 145,985-167,084 ops/s | 50-100 clients, same machine |
| NVMe sustained write | ~623 MiB/s | WD PC SN540 512 GB, 50 GiB transfer |
| Idle wall power | 12-14 W | Whole-system meter reading, Docker stack healthy |
| Source | eqi12-measurement-data | CC BY 4.0, measured 2026-08, Windows + Docker |
The decision, restated
Pick Immich if you want the Google Photos workflow (phones back up automatically, faces get found, sharing looks familiar) and you accept Docker Compose as the price. Pick PhotoPrism if you want one container and a prettier web idiom more than mobile auto-upload. Either way, on this class of hardware the database and cache will outrun your needs by orders of magnitude — the constraints that actually shape the project are storage capacity, first-import ML time, and whether you build the three-copy backup habit. The component benchmark data is public if you want to sanity-check your own machine against ours before committing a weekend to the migration.
Frequently asked questions
Is a mini PC powerful enough to run Immich? For a household library, yes. On our EQi12 the components Immich depends on measured far above household needs (PostgreSQL at 3,323-4,385 TPS, Redis above 145k ops/s, NVMe at ~623 MiB/s writes). These are component benchmarks rather than an end-to-end Immich test, but they establish that this hardware class does not bottleneck the boring parts of a photo server.
How much storage does a self-hosted photo library need? Plan 3-5 MB per JPEG and 30-60 MB per minute of 1080p video. A 400 GB allocation holds roughly 80,000-130,000 photos. Our EQi12’s 512 GB NVMe is shared with the OS, so a growth plan — external SSD, network share, or a NAS later — belongs in the design, not the wishlist.
Does Immich need a GPU for face recognition? No. The ML service runs on CPU by default. On a 6C/8T chip like the i3-1215U, the first full-library import takes hours of background compute; after that, daily increments are small. We did not benchmark Immich’s ML pipeline itself and do not quote import durations.
What does running a photo server 24/7 cost in electricity? With a measured 12-14 W idle at the wall, expect roughly 8.7-10.2 kWh per month — about $1.50-1.75 monthly at $0.17/kWh. The sustained-load peak of 37 W is reached rarely on a photo workload, mostly during initial ML processing.
Immich vs PhotoPrism for a first self-hosted library? Immich for the Google Photos-shaped experience and first-class mobile auto-upload; PhotoPrism for a single-container setup with higher RAM appetite and no native auto-upload. Both run fine on 16 GB mini PCs; the choice is about workflow, not hardware fit.