PhotoPrism

Last reviewed Aug 26, 2026 · 912 words

PhotoPrism is the right choice for a library that already exists as folders on a disk, and the wrong choice for someone whose real goal is a phone backup replacement for Google Photos. It indexes what you point it at, classifies and face-matches everything locally without any cloud, handles RAW files better than any competitor, and does all of that with no native mobile app: phone uploads go through a PWA or a WebDAV client. Read that trade the right way round and you will be happy. Read it the wrong way and you will migrate to Immich in 6 months.

Use MariaDB from day one

PhotoPrism can run on SQLite and the quick-start command does. Do not. The index for a 50,000-photo library holds millions of rows across faces, markers, labels, and file metadata, and SQLite starts to feel it under concurrent indexing and browsing. The official compose file ships with MariaDB for a reason, and migrating later is a re-index. This is the stack I would start with:

services:
  photoprism:
    image: photoprism/photoprism:latest
    ports:
      - "2342:2342"
    environment:
      PHOTOPRISM_ADMIN_USER: "admin"
      PHOTOPRISM_ADMIN_PASSWORD: "change-me-8-chars-min"
      PHOTOPRISM_SITE_URL: "https://photos.example.com/"
      PHOTOPRISM_DATABASE_DRIVER: "mysql"
      PHOTOPRISM_DATABASE_SERVER: "mariadb:3306"
      PHOTOPRISM_DATABASE_NAME: "photoprism"
      PHOTOPRISM_DATABASE_USER: "photoprism"
      PHOTOPRISM_DATABASE_PASSWORD: "change-me-too"
      PHOTOPRISM_READONLY: "true"
    volumes:
      - /srv/photos:/photoprism/originals
      - ./storage:/photoprism/storage
    depends_on: [mariadb]
    restart: unless-stopped
  mariadb:
    image: mariadb:11
    command: --innodb-buffer-pool-size=512M --transaction-isolation=READ-COMMITTED
    environment:
      MARIADB_ROOT_PASSWORD: "root-change-me"
      MARIADB_DATABASE: "photoprism"
      MARIADB_USER: "photoprism"
      MARIADB_PASSWORD: "change-me-too"
    volumes:
      - ./db:/var/lib/mysql
    restart: unless-stopped

Two mounts do all the work. originals is your photos; storage is everything PhotoPrism generates, meaning thumbnails, the sidecar folder, and caches. Back up the originals and the database dump. The thumbnails are rebuildable.

Indexing is a one-time tax, and it is a big one

The catalogue's 2 GB minimum is the floor for browsing an indexed library. The first index of a large collection is a different beast: PhotoPrism runs TensorFlow classification, face detection, and thumbnail generation for every file, and on a 4-core mini PC I would plan for roughly 1 to 3 seconds per JPEG and several times that per RAW, which puts a 100,000-image archive somewhere between a day and a long weekend. Give it 4 GB and swap during that window, run it on the box with the fastest disk you have, and do not judge the app's performance until it finishes. After that, incremental indexing of a week's phone photos takes seconds.

Two things trip people here. The default image assumes a CPU with AVX instructions for TensorFlow, so a 10-year-old Celeron or some low-power ARM boards need a different tag or the classification disabled. And the browser tab is not the indexer; kick it off from Library, then close the tab and check back, because the job runs server-side.

Originals stay yours, and the sidecar proves it

PHOTOPRISM_READONLY: "true" is the setting I care most about. It stops the app from ever writing into your originals folder, which means no scanner bug, no accidental delete, no re-encode can touch the files you spent 15 years collecting. Edits, labels, favourites, and face names go into the database and into YAML sidecar files under storage/sidecar, one per photo. Those sidecars are plain text, diffable, and readable without PhotoPrism, so the metadata you add is portable rather than trapped. If you already keep the archive on a NAS, mount it read-only into the container and let the backup post cover the originals as it would any other folder.

Phone uploads work, through WebDAV

There is no PhotoPrism app in the app stores. The web UI installs as a PWA and is fine for browsing, but background camera-roll backup, the feature that made Google Photos sticky, needs a third-party WebDAV client such as PhotoSync on iOS or Android pointed at the import or originals endpoint. It works, it is reliable, and it is one more thing to configure per phone. Immich ships native apps with background backup built in, and that single feature is why the two projects split the photos category between them: Immich for the phone-first household, PhotoPrism for the archive-first photographer. The full comparison goes through the rest.

Some features sit behind a membership

The fuller multi-user account management with per-user roles, plus a handful of other conveniences, sits behind the paid PhotoPrism membership tiers at last check rather than in the free AGPL build. A single-user instance for a family that shares one login loses nothing. A household that wants each person to have a private library should price the membership or look at Immich, where per-user accounts are free.

What I'd do

Mount the existing archive read-only, MariaDB alongside, 4 GB of RAM on a box with a fast SSD for the storage folder, and let the first index run over a weekend. Keep the sidecars and a nightly mariadb-dump in the same backup job as the originals. Use it as what it is: a searchable, face-aware, RAW-literate front end for photos you already keep in folders. If the phone is the camera and the folders do not exist yet, start with Immich instead and revisit PhotoPrism when the archive is worth curating.