Self-hosted фото: Immich, PhotoPrism и Ente — три модели хранения

Аннотация

Сравнения self-hosted фото обычно сводятся к списку функций: есть ли мобильное приложение, ищет ли по лицам, сколько ест памяти. Между тем у Immich, PhotoPrism и Ente разная архитектура хранения, и именно она определяет, что произойдёт, когда вы потеряете базу, где будет считаться ML и чем обернётся обновление через год. Этот обзор разбирает три модели: база как источник истины, индекс над папкой оригиналов и хранилище непрозрачных зашифрованных блобов с иерархией ключей. Данные и версии — на 1 ноября 2026 года: Immich v3.3.5 (21 октября 2026), PhotoPrism 261029-963b58c50 (29 октября 2026), Ente Photos v1.3.67 (30 октября 2026)¹²³.

Допущение, которое здесь принимается: одна машина с Docker Compose, библиотека от десятков тысяч до нескольких сотен тысяч ассетов, семья из нескольких человек, без кластера и без внешнего S3 у Immich и PhotoPrism. Для больших инсталляций выводы про хранение остаются, а числа по памяти и диску нужно пересчитывать.

Короткий вывод. Immich — приложение с базой в роли источника истины: без Postgres библиотека превращается в набор файлов с UUID-именами. PhotoPrism — индекс над папкой оригиналов: индекс можно потерять и пересобрать, заплатив временем. Ente — сервер, который не видит ваши фотографии: база хранит зашифрованные ключи и метаданные, и без неё даже целые блобы не расшифровать⁴⁵⁶.

Введение

Актуальность. Immich за пару лет превратился в самого заметного кандидата на замену Google Photos, PhotoPrism остался лагерем тех, кто хранит архив папками, а Ente занял нишу «облако, которому не нужно доверять». Публичные сравнения при этом почти всегда меряют одно и то же: наличие лиц, скорость интерфейса, минимальную память. Вопросы, которые реально решают судьбу библиотеки, звучат иначе: что я потеряю, если умрёт диск с базой; сколько будет стоить пересобрать индекс; где хранятся эмбеддинги лиц и кто их видит; что сломается при переходе на следующую мажорную версию⁴⁷⁸.

Цель — показать, что три проекта решают одну задачу тремя разными способами, и вывести из этого практические следствия для бэкапа, ML и эксплуатации. Заодно проверить, насколько распространённые советы из сравнений соответствуют текущей документации: часть из них устарела настолько, что мейнтейнеры Immich публично поправляют советчиков⁹.

Границы. Рассматриваются только три серверных продукта в self-hosted развёртывании; Nextcloud Photos, LibrePhotos, PhotoStructure и облачные тарифы остаются за рамками. Собственных замеров скорости индексации здесь нет: ни один из проектов не публикует воспроизводимый бенчмарк, а community-числа несопоставимы по железу и размеру библиотеки — это ограничение зафиксировано отдельно⁹.

Три модели хранения

Immich: база — источник истины

Ключевая фраза в документации Immich звучит буднично, но определяет всё остальное: «It does not scan the library folder, so database backups are essential»⁴. Приложение не выводит библиотеку из файлов на диске — оно хранит её в Postgres и ссылается на файлы. Отсюда следует цепочка решений, которые иначе выглядят произвольными.

Файлы по умолчанию лежат с именами-UUID: при выключенном Storage Template Immich сохраняет имена в виде случайной строки, чтобы избежать коллизий, а оригинальные имена приходится возвращать отдельной job-миграцией¹⁰. Включённый шаблон раскладывает ассеты по путям вида Year/Year-Month-Day/Filename.Extension и умеет перекладывать уже загруженное — но это именно операция над файлами, а не источник метаданных¹¹. Внешние библиотеки (External Libraries) позволяют подключить существующую папку, однако метаданные, добавленные в Immich — альбомы, описания, — живут только в базе: при перемещении файла внутри библиотеки они теряются при следующем сканировании, и это признано известной проблемой¹².

Требования к железу вытекают из той же модели. Минимум — 6 ГБ RAM и 2 ядра, рекомендуется 8 ГБ и 4 ядра; файлы Postgres обычно занимают 1–3 ГБ, и им нужен локальный SSD, «never a network share of any kind»¹³. Отдельно оговорено: если в Docker включены лимиты ресурсов, Postgres нужно не меньше 2 ГБ¹³. Сгенерированный контент — превью и транскодированное видео — добавляет к библиотеке в среднем 10–20 % объёма, причём на каждый ассет создаётся три вида превью: blurred thumbhash, WebP-preview и JPEG-thumbnail¹³¹⁰.

Версия 3.0 сделала эту модель ещё жёстче: поддержка pgvecto.rs удалена, и DB_VECTOR_EXTENSION=pgvecto.rs теперь просто выбрасывает ошибку¹⁴¹⁵. Векторный индекс — часть схемы базы, а не приложение к ней; поэтому Immich и поставляет собственный образ Postgres с скомпилированным расширением, а не подключается к вашему общему кластеру¹⁶.

PhotoPrism: оригиналы — архив, индекс — производное

PhotoPrism устроен зеркально. Оригиналы лежат в папке originals, и проект обещает: «PhotoPrism will generally not move, rename, or otherwise modify the files in this folder unless a user requests it»⁵. Всё остальное — база index.db, превью, YAML-sidecar-файлы с метаданными, JSON от ExifTool — живёт в отдельной папке storage⁵. Индекс можно потерять: при восстановлении из одних оригиналов достаточно полного пересканирования, чтобы заново создать sidecar-файлы и превью¹⁷.

Цена этой модели — база как узкое место. По умолчанию используется SQLite с DSN index.db?_busy_timeout=5000; документация прямо говорит, что SQLite годится для «small libraries with a few thousand files», а при росте индекса и числа одновременных обращений начинает блокировать запись, вплоть до ошибок и таймаутов при индексации⁷. Отдельно указан лимит: на SQLite PhotoPrism ограничивает индексацию четырьмя воркерами независимо от размера хоста, «to avoid database is locked contention»¹⁸. Для больших библиотек рекомендуется MariaDB 10.5.12+, где имеет смысл поднять InnoDB buffer pool до 1–2 ГБ и следить, чтобы свободных страниц было не меньше 5 %¹⁹¹⁸.

Свежая деталь, которая меняет расклад: сборка от 29 октября 2026 добавила экспериментальную поддержку PostgreSQL 16+²²⁰. Экспериментальную буквально: «The database schema may still change without migrations, so you should not use it for a library you depend on»²⁰. То есть у PhotoPrism теперь три варианта базы, и выбирать между ними придётся по нагрузке, а не по вкусу.

Ente: непрозрачные блобы и иерархия ключей

Ente — не «фотосервис с шифрованием», а хранилище зашифрованных объектов. Клиент генерирует masterKey, из пароля выводится keyEncryptionKey (Argon2id через libsodium), master key шифруется им и в таком виде уходит на сервер; каждая коллекция получает collectionKey, каждый файл — свой fileKey, и по проводу идут только зашифрованные данные⁸. Файлы шифруются потоково (crypto_secretstream_*, XChaCha20-Poly1305), ключи — crypto_secretbox_easy (XSalsa20-Poly1305)⁸.

Практическое следствие сформулировано в документации по бэкапам прямым текстом: «While the actual encrypted photos are indeed stored in the object storage, this encrypted data will not be usable without the database since the database contains information like a file specific encryption key»⁶. Для расшифровки нужны три вещи: сами зашифрованные данные из object storage, зашифрованные ключи файлов и коллекций из базы и master key, который выводится из вашего пароля⁶. Разработчики честно советуют новичкам начать с plaintext-бэкапа фотографий через CLI или десктопное приложение, а к бэкапу инстанса переходить, когда части системы уже понятны⁶.

Сервер при этом сознательно «глупый»: Museum — один статически собранный бинарник на Go, который можно запустить и без Docker, собрав из исходников; ему нужны Postgres и S3-совместимое хранилище²¹²². В поставке по умолчанию это MinIO, а репликация на три бакета выключена и включается флагом replication.enabled²³²². Минимальные требования скромные на фоне Immich: 1 ГБ RAM и 1 ядро²⁴. Но и поддержка self-hosting в README обозначена без иллюзий: «we will currently not be able to prioritize support queries related to self hosting»²².

Что это значит для бэкапа

Разные модели хранения дают три разных контракта на восстановление, и путать их дорого.

У Immich база незаменима, поэтому порядок бэкапа зафиксирован: сначала база, потом файлы, а лучше — остановить immich-server на время копирования, чтобы наборы не разъехались. Обратный порядок опасен: восстановленная база может ссылаться на файлы, которых в бэкапе нет⁴. Автоматические дампы создаются ежедневно в 2:00 и хранятся в количестве 14 по умолчанию; они лежат в UPLOAD_LOCATION/backups, но не содержат ни фото, ни видео — только метаданные⁴. Восстановление через CLI требует «completely fresh install»: если сервер уже запускался, посыпятся конфликты Postgres, и папку с данными придётся удалить⁴. Это не мелочь, а процедура, которую нужно один раз прогнать на тестовом стенде до аварии.

У PhotoPrism бэкап — это оригиналы плюс дамп индекса; всё остальное восстанавливается пересборкой¹⁷. Дампы с версии 240523 создаются ежедневно, по умолчанию хранятся 3 копии, а команда photoprism backup -i умеет писать в stdout, чтобы файл не оставался внутри контейнера²⁵. Восстановление возвращает не только фото, но и пользователей, пароли, сессии и настройки — то есть после восстановления логиниться нужно учёткой из бэкапа¹⁷. Если базы нет вовсе, остаются YAML-файлы: часть метаданных и альбомы из них восстанавливаются, но имена людей и кластеры лиц придётся собирать заново¹⁷.

У Ente бэкап — это конфигурация (museum.yaml, credentials.yaml), том базы, том object storage и пароль. Документация отдельно предупреждает о типичной ошибке: люди аккуратно реплицируют бакеты и забывают про базу, после чего зашифрованные фото остаются, а ключей к ним нет⁶. Совет «проверьте полное восстановление, а не только наличие файлов» здесь не вежливость, а единственный способ узнать, что бэкап рабочий⁶.

Общая закономерность: чем «умнее» сервер, тем больше в бэкапе доля базы и тем меньше шансов восстановиться вручную. Immich требует базы и дисциплины порядка копирования; PhotoPrism прощает потерю индекса ценой часов пересчёта; Ente не прощает потери базы вообще, зато сама база не содержит читаемых метаданных⁴¹⁷⁶.

ML: где считаются эмбеддинги

Immich: серверный конвейер

Immich считает ML на сервере, в отдельном контейнере immich-machine-learning: там CLIP-эмбеддинги для семантического поиска и распознавание лиц²⁶. Поиск идёт через Postgres и расширение VectorChord, а не через отдельный поисковый движок²⁵. Модель CLIP выбирается по языку: для англоязычных запросов предлагается курируемый список от крупных к мелким, для остальных — многоязычные семейства. Тонкость, важная для русского: модели nllb ожидают запрос на языке из настроек пользователя, а xlm и siglip2 понимают текст независимо от выбранного языка²⁵. В примерах документации фигурирует, например, ViT-B-16-SigLIP__webli²⁵.

Механика поиска опирается на контрастное обучение CLIP: модель учится сопоставлять изображение с описанием, предсказывая, какая подпись подходит к картинке, и после обучения текст становится способом адресовать визуальные понятия без отдельного классификатора²⁷. Лица — отдельная ветка: Immich использует модели InsightFace (antelopev2, buffalo_l, buffalo_m, buffalo_s), причём в README зафиксировано разрешение от автора моделей и прямое ограничение: разрешение не распространяется на перераспространение или коммерческое использование моделей третьими лицами²⁸. Такие распознаватели обучают метрическим лоссом вроде ArcFace: он вводит угловой отступ между классами и повышает разделимость эмбеддингов²⁹. Для self-hosted это значит, что вы не можете просто выложить веса в свой реестр.

Аппаратное ускорение есть, но помечено экспериментальным: CUDA (compute capability 5.2+, драйвер не ниже 545), ROCm, OpenVINO, ARM NN и RKNN; ROCm-образ требует минимум 35 ГиБ свободного места, а на Intel iGPU ожидается повышенный расход RAM²⁶. С версии 3 контейнер ML на amd64 требует микроархитектуру x86-64-v2, последняя версия с поддержкой v1 — 2.7.5¹³¹⁴. Для владельца старого NAS это не абстракция, а причина, по которой обновление не запустится.

PhotoPrism: фиксированный словарь и отдельный детектор

PhotoPrism тоже считает на сервере, но по другой схеме: встроенный классификатор на ONNX раздаёт метки из фиксированного словаря ImageNet-1k — тысяча классов, одинаковых для всех моделей³⁰. Модель по умолчанию — EfficientFormerV2-S2: 82.2 % Top-1 на ImageNet, 12.7 млн параметров; замеры авторов документации дают 71 мс p50 и 74 мс p95 на картинку на Intel Core i5-7500T, а на корпусе из 402 фотографий Wikimedia модель поставила хотя бы одну метку 81.8 % изображений³⁰. Open-vocabulary и подписи — только через внешний vision-сервис (в том числе Ollama), а не встроенным классификатором³⁰.

Лица обрабатываются тремя стадиями: детекция на 720-пиксельном превью, эмбеддинг, кластеризация алгоритмом DBSCAN³¹³². Детектор по умолчанию — YuNet, компактная ONNX-модель без привязки к GPU; в статье авторов у неё 75 856 параметров, 81.1 % mAP на WIDER FACE hard и 1.6 мс на кадр 320×320 на i7-12700K³³³². Эмбеддинг — SFace для новых библиотек и FaceNet для созданных раньше: векторы разных моделей несравнимы, поэтому смена модели требует photoprism faces migrate, которая пересчитывает все лица и сохраняет назначенных людей, а пороги кластеризации калибруются под модель и не переносятся между ними³². Для сотен тысяч лиц кластеризация идёт часами, и в логах это выглядит как «matched 90,500 markers every 15 minutes or so»¹⁸.

Разница с Immich принципиальная: Immich ищет по описанию на естественном языке, PhotoPrism — по меткам из ограниченного словаря плюс фильтрам (место, камера, человек, папка). Для «найди кота на диване» этого мало; для «покажи всё, что помечено beach, за 2019 год» — достаточно, и работает предсказуемо на CPU.

Ente: ML на устройстве

Ente выбрал третий путь: машинное обучение целиком на клиенте. Документация формулирует это без оговорок — «All machine learning happens entirely on your device — your photos and ML data are never sent to Ente’s servers»³⁴. Это касается и лиц, и magic search: приложение скачивает оригиналы, строит индексы локально, шифрует их и синхронизирует между устройствами³⁴.

Следствия неочевидны и их стоит проговорить. Во-первых, веб-версия остаётся без ML вообще: photos.ente.com умеет только поиск по дате, имени файла, описанию и альбому³⁴. Во-вторых, первичная индексация — это скачивание всей библиотеки на устройство; разработчики советуют начинать с десктопа и включать ML до импорта большой библиотеки, чтобы не качать файлы дважды³⁴. В-третьих, на телефонах с 4–6 ГБ RAM индексация больших библиотек влияет на производительность, и локальную индексацию на мобильном можно отключить, оставив её десктопу³⁴. Наконец, управление кластерами лиц доступно только на мобильном: десктоп умеет смотреть и назначать имена, но не менять группировки³⁵.

Сравнение по осям получается такое. Серверный ML (Immich, PhotoPrism) даёт общий индекс для всей семьи и не требует мощного клиента, но платит GPU/CPU на сервере и доверием к серверу: он видит расшифрованные фото. Клиентский ML (Ente) снимает вопрос доверия и не требует серверного GPU, но переносит стоимость на каждое устройство и лишает веб-поиска. Промежуточный вариант — PhotoPrism с его фиксированным словарём: дёшево по железу, предсказуемо, но без открытого словаря²⁶³⁰³⁴.

Телефон и синхронизация

Immich здесь сильнее всех по механике: фоновая загрузка включается в приложении, альбомы синхронизируются в одну сторону (с телефона на сервер), а функция Free Up Space удаляет с устройства то, что уже подтверждено на сервере — пакетами по 2000 ассетов на Android и 10 000 на iOS³⁶. Документация честно перечисляет грабли: при использовании iCloud удаление через Free Up Space удалит фото и из iCloud, потому что синхронизация двусторонняя; а бэкап папки WhatsApp приведёт к тому, что после очистки в чатах останутся битые превью³⁶. Для семейного сценария важнее другое: приложение и сервер должны совпадать по мажорной и минорной версии, иначе логин ломается¹⁰.

PhotoPrism в документации описывает загрузку с телефона через браузер, WebDAV в папку импорта или автоматический импорт с задержкой безопасности, а сам импорт недоступен в read-only режиме, потому что требует записи в originals³⁷⁵. Это не хуже и не лучше — это другая модель: вы не «бэкапите камеру», а складываете файлы в архив.

Ente ближе к Immich по UX (нативные приложения и автоматический бэкап камеры), но с двумя ограничениями из-за шифрования: индексация тянет оригиналы на устройство, а часть операций с лицами доступна только на телефоне³⁴³⁵. Плюс семейные сценарии упираются в то, что ML-данные и метки лиц не шарятся между аккаунтами, а дедупликация фото между семейными аккаунтами не делается³⁸.

Цена эксплуатации и обновлений

Immich — самый быстрый по фичам и самый дорогой по вниманию. Переход на v3 принёс длинный список ломающих изменений: удалённые переменные окружения, изменённый формат ошибок (Zod вместо class-validator, X-Correlation-ID вместо поля в теле), переименованные и удалённые эндпоинты¹⁴. Формально «для большинства пользователей обновление работает как всегда», но третьи инструменты и скрипты ломаются¹⁵. Плюс связка «расширение — мажор Postgres — схема Immich»: пропущенная промежуточная версия базы приводит к отказу сервера стартовать, и лечится это не удалением каталога, а чтением release notes¹⁶¹⁵. Практики добавляют к этому гигиену автовакуума на таблицах эмбеддингов и оценку «несколько единиц гигабайт базы на 100 тыс. ассетов» — цифра совпадает с порядком из документации³⁹¹³.

PhotoPrism движется медленнее и версионируется датами сборки, но и у него есть свои переходы: SQLite → MariaDB (переносить только через photoprism database transfer, иначе схема останется неоптимальной), теперь ещё и экспериментальный PostgreSQL, у которого схема может меняться без миграций²⁰¹⁸. Отдельного внимания заслуживает безопасность по умолчанию: в сборке 261029 MCP включён для подходящих пользователей, и отключается либо в настройках аккаунта, либо глобально через PHOTOPRISM_DISABLE_MCP².

Ente — самый спокойный по серверным обновлениям и самый бедный по поддержке: один бинарник, пара зависимостей, но self-hosting официально не приоритет, а документация местами «not readily documented»²². Многопользовательская модель у него фактически «один человек — один аккаунт»: общие альбомы есть, но общая библиотека и общий индекс — нет³⁸.

Противоречия и пробелы

Первое противоречие — источники советов. В обсуждении про железо для 750 тыс. ассетов один из ответов (сгенерированный LLM) предлагает планировать RAM под индекс Typesense; мейнтейнер Immich отвечает: «we haven’t used typesense for a while»⁹. Тот же ответ советует 32–64 ГБ RAM, тогда как документация говорит про 8 ГБ для обычной инсталляции — оба числа могут быть верны для своих сценариев, но читатель не увидит разницы, если не сверит источник¹³⁹.

Второе — числа, которых нет. Ни Immich, ни PhotoPrism, ни Ente не публикуют воспроизводимого бенчмарка индексации целой библиотеки: сколько ассетов в час на каком железе. В обсуждении Immich пользователи сообщают о примерно неделе на ~250 тыс. внешних ассетов с GPU RTX 4080 и о похожем сроке с Intel iGPU через OpenVINO — это полезные ориентиры, но не измерение⁹. У PhotoPrism есть только документированные тайминги классификации одного изображения и предупреждение, что распознавание лиц на сотнях тысяч лиц идёт часами³⁰¹⁸.

Третье — цена шифрования. Публичных замеров накладных расходов E2EE у Ente нет: сколько добавляют заголовки secretstream и во что обходится отсутствие серверной дедупликации, не измерено. Что дедупликации между семейными аккаунтами нет, документация говорит прямо³⁸; что сервер не может дедуплицировать блобы в принципе — вывод из архитектуры, а не заявление проекта⁸⁶.

Четвёртое — качество кластеризации лиц. Единственные числа, которые публикуют проекты, — метрики моделей на академических датасетах (ImageNet, WIDER FACE), а не доля правильно сгруппированных людей в личной библиотеке³⁰³³. Любые сравнения «у Immich лица точнее» в статьях остаются частным опытом.

Как выбирать

Если нужен Google Photos на своём железе и семья с телефонами. Immich: фоновая загрузка, общий индекс, семантический поиск, и цена — дисциплина бэкапа (база + порядок копирования + тренировка восстановления) и готовность читать release notes перед каждым мажором⁴³⁶¹⁴.

Если есть архив папками на 10 лет и не хочется зависеть от приложения. PhotoPrism: оригиналы не трогаются, индекс пересобирается, MariaDB спасает от блокировок SQLite, а экспериментальный PostgreSQL лучше не ставить под библиотеку, которую нельзя потерять^5172018. Для семьи проект сам советует отдельные инстансы вместо одной общей библиотеки — с общими настройками, правами на файлы и дублями иначе придётся разбираться вручную⁴⁰.

Если модель угрозы включает «сервер прочитает мои фото». Ente: сквозное шифрование, ML на клиенте, сервер не видит ни фото, ни индексов. Цена — потеря веб-поиска, скачивание библиотеки на устройство для индексации и бэкап, в котором пароль такой же обязательный элемент, как база⁸⁶³⁴.

Гибрид. Рабочая схема, которую применяют практики: Immich как ежедневный драйвер, PhotoPrism или Ente как холодный архив с независимым бэкапом. Это не рекомендация вендоров и не бесплатно: два индекса, две политики обновлений, двойное место на диске. Но именно так снимается главный риск — «одно приложение с одной базой решает, увижу ли я свои фото через пять лет».

Заключение

Три проекта выглядят конкурентами, но отвечают на разные вопросы. Immich отвечает «как сделать удобно», и его архитектура — база плюс ссылки на файлы — следует из этого ответа. PhotoPrism отвечает «как сохранить архив», и поэтому оригиналы неприкосновенны, а индекс расходуем. Ente отвечает «как не доверять серверу», и поэтому сервер хранит блобы и ключи, а не фотографии.

Практический вывод прост: выбирать нужно не по списку функций, а по тому, какую потерю вы готовы пережить. Потеря базы Immich — это потеря альбомов, лиц и истории, которую не восстанавливает пересчёт файлов. Потеря индекса PhotoPrism — это часы пересчёта и потерянная ручная работа по людям. Потеря базы Ente — это потеря доступа к данным, которые физически целы. Ни один из трёх вариантов не отменяет правила, которое старше всех них: бэкап проверяется восстановлением, а не наличием файлов⁴¹⁷⁶.

Quality Metrics