There was a fantastic article by one of the frontend engineers at Google about how they built the UI for photos to be scalable: https://medium.com/google-design/google-photos-45b714dfbed1

There's no reason why the lessons learnt here couldn't be incorporated into an OS project.

I tested it a few months ago hosted on my desktop (Ryzen 2600 6 core CPU, 16gb of RAM) with my entire photo library of around 100k photos - or about 60gb of data, and the performance was better than I expected. The ML image classification stuff it does took a few hours for sure, I left it go overnight, but then in the morning the ability to filter for specific classifications or jump to a specific date was pretty much as fast as you'd expect it to be (almost instant). This was using the default SQLite config.

The one thing I wished was that the ML Classification stuff it did was better - because it was nowhere near as good as what Google does with Photos, and nowhere near as useful for that reason. I still deeply miss Google Photos.

For context, my setup is pretty old fashioned these days. I plug my phone in, and use Shotwell to import the photos into my local photo library. Duplicati does a backup of all my photos once a week to Backblaze. Photoprism reads from my local copy and allows me to effectively browse my photos at home.

Sadly it won't.

I have been following it since release of OwnPhotos. Back then it was a messy university project of the original developer mixing different tech to achieve the goal. It simply stopped working with bigger sets of images.

I tried this fork as well, it has the same problem. Normally I would provide some pull requests but in this case the code base seemed too much hacked together from random things.

What doesn't work is the backend indexing part.

My personal photo archive is 100k+

I'll test this out and report back.