Ищем замену MinIO в условиях импортозамещения: опыт тестирования трех S3-совместимых хранилищ

Привет, я Иван Засухин, DataOps Лаборатории искусственного интеллекта департамента больших данных Россельхозбанка. Мы одна из команд платформы RAISA (RSHB AI Systems and Applications), отвечаем за инструменты, которые связаны с данными и их обработкой: Оркестрация (Apache Airflow), Compute( Apache Spark и Apache Trino), Хранение (S3 и Qdrant), интерфейсы взаимодействия с источниками данных (python-модули и кастомные операторы). В команде я занимаюсь развитием инструментов и их дальнейшим сопровождением.

Как эффективно заменить MinIO, если это одно из главных объектных хранилищ команды и ИИ-платформы большого банка? В этой статье поделюсь результатами двух этапов тестирования S3-совместимых хранилищ. Сравнивали три решения: коммерческую российскую разработку "Закрома", опенсорс-решения RustFS и SeaweedFS. Тесты проводились на реальных стендах с нагрузками, приближенными к боевым. Спойлер: однозначного победителя нет, но у каждого кандидата есть четкие сценарии применения.

В конце 2025 года мы, как и многие команды, использующие S3-совместимые хранилища, столкнулись с неприятным сюрпризом от MinIO. Компания резко изменила курс в сторону жесткой монетизации, что больно ударило по пользователям комьюнити-версии. Для нас, как для разработчиков ИИ-платформы РСХБ, это стало существенным ограничением, поскольку объектное хранилище данных – это один из ключевых инфраструктурных компонентов платформы во всех сценариях работы – и в DataOps-процессах, и в MLOps, и в AnalyticsOps.

Вот что конкретно произошло и почему мы сочли это важным:

1. Полный отказ от разработки Community Edition. Репозиторий Minio на Github был переведен в архивный статус. Можно продолжать использовать, но уже не будет ни улучшений, ни исправлений в критических уязвимостях. Все это теперь перетекло в Enterprise-версию.
2. Удаление веб-консоли из Community-сборок заметно снизило удобство администрирования — мы активно использовали UI для мониторинга состояния кластера, просмотра метрик и быстрых операций с бакетами.
3. Прекращение публикации официальных Docker-образов. Это усложнило процесс развертывания и обновления в наших CI/CD-пайплайнах, так как пришлось собирать образы самостоятельно или искать сторонние.

Ниже — скриншот официального анонса от разработчиков MinIO, который вызвал бурную дискуссию в профильных IT-чатах (источник — репозиторий MinIO (https://github.com/minio/minio/issues/21675#1), ноябрь 2025):

Реакция мирового комьюнити не заставила себя ждать: на Reddit, в GitHub Issues и Telegram-каналах (например, @minio_ru) разразились горячие споры. Многие восприняли это как "принудительный вендорлок" и начали активно искать альтернативы. Основные аргументы сообщества сводились к тому, что MinIO нарушил негласное правило "open source friendly" и фактически "залочил" своих бесплатных пользователей. Мы оказались в той же лодке.

Для нас, как для внутреннего продукта крупного государственного банка, критически важно использовать ПО с открытой лицензией типа Apache 2.0. Это гарантирует нам право свободно модифицировать исходный код, внедрять его в наш стек без ограничений по числу экземпляров и, что самое главное, не зависеть от внезапных изменений политики вендора в будущем. Именно поэтому мы не рассматривали варианты с проприетарными лицензиями или ограничениями по использованию (типа AGPL, которая могла бы наложить обязательства на наш внутренний код). В этом плане MinIO с его переходом на коммерческую модель перестал для нас быть безопасным с точки зрения долгосрочного планирования.

Как итог, мы запустили двухэтапное тестирование альтернативных инсталляций, чтобы найти замену, которая устроит нас и по скорости, и по функционалу, и по лицензионной чистоте.

Выбрали трёх кандидатов, каждый из которых олицетворял свой путь: проверенный временем open-source (SeaweedFS), технологичный новичок с заявленной простотой миграции с текущего решения (RustFS) и российский коммерческий продукт с поддержкой (Закрома). Эталоном во всех тестах оставался MinIO.

Первый этап тестирования мы проводили с целью оценить базовую функциональность, совместимость с нашими инструментами и сервисами, получали общее впечатление от работы с каждым решением.

Важные условия:

• MinIO брался как эталон и был развернут в кластерном режиме. Да, это дает ему преимущество в отказоустойчивости и потенциально в скорости. Однако он работает в окружении с другими сервисами (GitLab, Nexus и т.д.), что может влиять на результаты.
• SeaweedFS, RustFS и Закрома тестировались в standalone-режиме.
• Инструменты: python с boto3 и rail_connectors (наша библиотека для подключения к источникам данных, в неё имплементирован класс MinioConnection — обертка над minio sdk) для сценариев, приближенных к продуктовым.
• В каждом объектном хранилище был создан бакет на 50 ГБ для тестирования.

Совместимость и интеграция

Прежде чем перейти к результатам, важно понять, как мы используем S3 в платформе ИИ и что для нас критично. Платформа — это DataOps/MLOps/AnalyticsOps-решение RAISA (RSHB AI Systems and Applications). На "Раисе" живут в РСХБ все модели ИИ, огромное количество процессов аналитики и обработки данных, а также дата-приложения, и S3-хранилище в ней является центральным узлом для хранения всех типов данных. Выделим ключевые сценарии:

• Хранение данных для аналитики и ML: датасеты для обучения моделей (от сотен МБ до сотен ГБ), подготовленные витрины в Parquet/ORC для аналитиков, исторические срезы для воспроизводимости экспериментов.
• Артефакты пайплайнов: чекпоинты моделей, веса, логи экспериментов, метрики, результаты валидации. Эти данные активно перезаписываются и удаляются в процессе работы.
• Интеграция с вычислительными движками: Spark и Trino постоянно читают данные из S3 при выполнении аналитических запросов и обучении моделей. Скорость чтения напрямую влияет на время выполнения задач.

С какими требованиями подходили к тестированию?

• S3-совместимость на уровне API: бесшовная работа с boto3 и нашими внутренними библиотеками (rail_connectors).
• Поддержка STS и IAM: возможность выдавать временные токены, управлять доступом на основе единой ролевой модели, реализованной в Keycloak.
• Шифрование: наличие всех трех методов SSE (S3, C, KMS).
• Стабильность и предсказуемость: никаких сюрпризов при заполнении диска, обрывах соединения, высоких нагрузках.
• Производительность: должна быть сравнима с Minio на разных типах нагрузок

Теперь перейдем к тому, как кандидаты справились с этими требованиями.

Функциональные тесты

Все три кандидата успешно работают с boto3 — методы загрузки, выгрузки, получения статистики и управления бакетами протестированы. C rail_connectors ситуация немного различается: у Закрома, RustFS и SeaweedFS выявлено отсутствие некоторых параметров (chunksize в upload), хотя multipart upload поддерживается. MinIO, как эталон, работает без замечаний.

Пользователями S3 в нашей платформе являются не только технологические процессы, но и обычные сотрудники банка. Действия этих пользователей должны быть аудируемы, а значит нельзя просто раздать техническую учетную запись всем. Сотрудники банка иногда увольняются и переводятся между подразделениями, и вслед за этим должны изменяться их права. Для интеграции с банковской платформой аутенфикации мы используем стандартную технологию Security Token Service (STS). При переезде на новый продукт нам очень критична поддержка STS-токенов (Security Token Service) и полнота реализации стандарта:

• SeaweedFS поддерживает AssumeRole, GetFederationToken и IAM policies.
• RustFS – ограниченная поддержка (AssumeRole и IAM policies).
• Закрома –документация описывает настройку Keycloak для OIDC (OpenID Connect), но STS-токены не поддерживаются.

Важный момент для хранения чувствительных и конфиденциальных данных — шифрование: SeaweedFS и RustFS реализуют все три стандартных метода серверного шифрования (SSE-S3, SSE-C, SSE-KMS). Закрома на момент тестирования поддерживает SSE-S3, но SSE-C, которое активно нами используется в кейсах работы с моделями. Вендор нас уверил, что данная функциональность будет реализована в течении 2026 года.

Нагрузочное тестирование

Проведя тесты скорости чтения и записи (представлены на графике), мы получили следующие результаты:

Полные таблицы результатов тестов в спойлере (!)

По записи все три решения уступают эталонному MinIO: SeaweedFS отстает на 20–30%, RustFS и Закрома — в 1.5–2.7 раза (хотя у RustFS мы подозреваем деградацию диска). По чтению картина противоположная: SeaweedFS — абсолютный лидер, обгоняет MinIO в 5–6 раз, RustFS — в 2–4 раза быстрее, а Закрома держится на уровне эталона. Таким образом, SeaweedFS — выбор для сценариев с высокими требованиями к чтению, RustFS дает сбалансированный профиль, а Закрома, уступая по записи, показывает достойное чтение.

По удобству администрирования MinIO (до последних версий с урезанным UI и функционалом) остается для нас эталоном: полноценный UI, понятное управление пользователями, низкий порог входа. RustFS максимально к нему приближен — управление интуитивно, интерфейс нативно понятный. SeaweedFS не обладает нужными нам функциями в UI, управление ролями и пользователями только через Keycloak, что требует привыкания. Закрома — достаточно детальный продукт с многослойной архитектурой, интерфейс дружелюбный, потребовал немного времени для адаптации.

Разумеется, standalone-режим не является целевым для промышленной эксплуатации, но такое значительное отставание Закрома в одноузловой конфигурации нас насторожило. Мы обсудили эти результаты с вендором и определили, что причина в различии архитектурных решений: Закрома — это микросервисное решение с четким разделением на управляющий слой (Gateway, Core, Composer, Metadata Database) и слой хранения данных (ZDS — Zakroma Data Storage). В standalone-режиме все эти компоненты работают на одной ноде, и именно слой управления метаданными (PostgreSQL с шардированием, сервисы Core/Composer) создает дополнительную нагрузку, которая в одноузловой конфигурации "съедает" часть ресурсов и ограничивает пропускную способность. А в кластерной конфигурации нагрузка распределяется между узлами, а слой хранения ZDS с Erasure Coding должен раскрыть свой потенциал за счет параллельной записи на несколько дисков и узлов. Поэтому на больших объемах и в многопоточной нагрузке результаты должны были значительно улучшиться.

С этой надеждой мы и перешли ко второму этапу тестирования, целью которого было проверить системы в кластерной конфигурации, на больших объемах, в многопоточной нагрузке, а также оценить поведение при заполнении диска.

Конфигурация второго этапа: все S3-совместимые хранилища в кластерном режиме, MinIO также под нагрузкой с бакетом в 0.5 Тб. Остальные - с бакетами в 1.5 Тб. Инструментарий тот же – python с boto3.

Мы прогнали два основных блока:

1. Скоростные тесты – запись и чтение на разных объемах (от 100 КБ до 100 ГБ), в разное количество потоков (1, 4, 10). Получим ли мы результаты отличные от первого этапа?
2. Тесты отказоустойчивости – заполнение диска, прерывание и возобновление загрузки, удаление больших файлов. Попытались поломать хранилище в базовых сценариях.

Производительность тестов скорости записи и чтения

Полный каталог тестов и их таблицы с результатами будут приведены в спойлере в конце страницы. Здесь же продемонстрируем самые яркие отличия и, что важнее, привяжем их к реальным сценариям использования в платформе.

Запись 10 ГБ x 4 потока — работа с датасетами для обучения моделей. В нашем пайплайне дата-сайентисты постоянно загружают подготовленные выборки размером 5–20 ГБ для экспериментов, а аналитики — выгрузки из DWH для исследования гипотез. RustFS здесь показывает выдающиеся 255 МБ/с, что позволяет сократить время ожидания загрузки данных перед обучением с 8 минут до 2.5 минут. Это критично при A/B-тестировании гипотез, когда специалист перебирает десятки вариантов за день, а также для аналитиков, которые исследуют новые данные в рамках ad-hoc задач.

Запись 100 ГБ x 1 поток — загрузка исторических данных для нового исследования или аналитической задачи. В RAISA часто возникает потребность "поднять" архивный датасет для проверки гипотезы или воспроизведения результатов коллеги. Например, аналитик загружает историю транзакций за прошлый год, чтобы проверить новую метрику.

Здесь Закрома неожиданно вырывается вперёд с 94 МБ/с, обгоняя даже специализированные open-source решения. На практике это означает, что исследователь, который запускает новый эксперимент с историческими данными размером 100 ГБ, дождётся их загрузки за ~18 минут вместо ~29 минут на MinIO. Для дата-сайентиста это ощутимая разница, особенно если эксперимент требует нескольких итераций с разными срезами данных.

Запись100 ГБ x 4 потока — параллельная запись артефактов экспериментов. На платформе часто запускается несколько исследовательских задач одновременно (гиперпараметрическая оптимизация, ансамбли моделей, сравнение подходов), каждая из которых сохраняет чекпойнты, веса и логи. SeaweedFS здесь раскрывается на полную, выдавая 265 МБ/с — в 3 раза быстрее MinIO. На практике это означает, что при параллельной работе 4 специалистов мы упираемся не в диск, а в вычислительные мощности GPU, что является идеальным сценарием.

Запись:

По итогу тестирования скорости записи: RustFS – лидер на средних объемах (до 10 ГБ), почти в три раза быстрее MinIO. На 100 ГБ скорость снижается, но остается на достойном уровне. SeaweedFS – раскрывается на тяжелых файлах. На 100 ГБ в многопотоке показывает впечатляющие 265 МБ/с. Закрома – в кластерной конфигурации показывает результаты, сопоставимые с конкурентами. В сценарии 100 ГБ x 4 раза в 1 поток, Закрома даже опережает всех, включая SeaweedFS и RustFS, показывая 94 МБ/с против 89 и 93 МБ/с соответственно. Конечно, она уступает лидерам, но держится на уровне выше MinIO.

Чтение:

Чтение 100 МБ x 50 раз, 4 потока — это классическая OLAP-нагрузка от Trino или Spark, когда читают множество мелких файлов при выполнении аналитического запроса. В RAISA это повседневная задача от аналитиков: ad-hoc запросы к данным, построение отчетов. SeaweedFS и RustFS здесь показывают 237 и 223 МБ/с, что в 5 раз быстрее MinIO. Это означает, что интерактивный запрос к данным за 2025 год, который на MinIO выполнялся 2 минуты, на SeaweedFS отработает за 25 секунд. Для наших пользователей затраченное время из "подожду, схожу за кофе" превращается в "получил результат мгновенно", что напрямую влияет на скорость принятия решений.

Чтение 10 ГБ в 3 потока — часто это загрузка данных из больших таблиц для обучения моделей, когда дата-сайентист загружает подготовленный датасет целиком в память для работы. SeaweedFS (220 МБ/с) и RustFS (182 МБ/с) сокращают время загрузки с 9 минут до 2.5 минут. За день исследователь может перезапустить эксперимент 20–30 раз.

Чтение 100 ГБ в 2 потока — загрузка тяжелых артефактов, таких как подготовленные аналитические витрины в формате Parquet (например, агрегированные данные по всем клиентам за год), экспортированных датасетов после Feature Engineering (обогащенных признаков для обучения).

SeaweedFS показывает 171 МБ/с против 136 МБ/с у MinIO, сокращая время загрузки 100-ГБ артефакта с 25 минут до 20 минут, каждая такая задача будет завершаться на 5 минут быстрее. RustFS здесь неожиданно проседает до 124 МБ/с, уступая даже MinIO. Это говорит о проблемах с чтением очень больших объектов в этом движке. Данный нюанс стоит учитывать, если вы планируете хранить в S3 файлы размером более 50 ГБ: например, исторические срезы для аналитики, подготовленные датасеты для обучения или экспортные выгрузки в Parquet/ORC.

По итогу тестирования скорости чтения: SeaweedFS – абсолютный лидер. Обгоняет MinIO в 3–5 раз на всех объемах. RustFS – также значительно быстрее эталона, но на 100 ГБ уступает даже MinIO. Закрома – уверенно держится на уровне MinIO или чуть лучше.

Тесты надежности

В идеальном мире все программное обеспечение работает идеально: место не заканчивается, сеть гарантирована и никогда не пропадает, а сервера никогда не перегружаются нештатно. Но что будет, если идеальные условия были нарушены? Не приведет ли закончившееся место на одном сервере к полной потере данных? Мы протестировали и это.

Заполнение диска: загружали 1 ГБ файлы, пока место не кончится.

• MinIO – штатная ошибка QuotaExceeded.
• Закрома – ошибка превышения квоты, отработала корректно.
• RustFS – ошибка InternalError при записи, связанная с кворумом (при трех узлах требовалось 2, достигнуто 0, 3 отказали). Это требует внимания при проектировании отказоустойчивого кластера.
• SeaweedFS – ошибка Unknown после превышения лимитов.

Прерывание и возобновление загрузки (файл 100 МБ): все четыре системы справились штатно – загрузка прервалась и возобновилась корректно.

Удаление файла (100 ГБ):

Здесь Закрома показывает результат, который отличается от конкурентов. Это связано с архитектурными особенностями управления метаданными — они требуют более сложных операций при удалении. Данный фактор стоит учитывать при планировании операций с большими объемами данных.

Функциональный анализ

В ходе анализа документации мы детально прошлись по ключевым функциям каждого решения, чтобы оценить их зрелость и готовность к промышленной эксплуатации. Ниже — сравнение того, что эти функции дают на практике и как обстоят дела с их поддержкой в каждом из трех кандидатов.

1. Object Lock / WORM (Write Once, Read Many)

Что дает: режим, при котором файл нельзя удалить или перезаписать до указанной даты. Критично для хранения аудиторских логов, финансовых отчетов и других данных, подпадающих под регуляторные требования (например, 152-ФЗ).

У кого есть: Полноценная поддержка режимов governance и compliance реализована во всех трех решениях. MinIO, SeaweedFS и RustFS полностью поддерживают все режимы Object Lock, включая Legal Hold. Это стандартный S3-функционал (режим governance позволяет временно блокировать объект, но пользователи с определенными правами могут его удалить или перезаписать, тогда как compliance обеспечивает жесткую блокировку до истечения срока, которую не может снять даже администратор), предусмотренный спецификацией AWS S3 API, поэтому его наличие в том или ином виде ожидаемо для любого S3-совместимого хранилища.

2. Версионирование объектов

Что дает: возможность хранить все версии файла и откатываться к любой из них. В наших пайплайнах это спасает при случайном перезаписывании подготовленного датасета или артефакта эксперимента — можно быстро вернуться к предыдущей версии без восстановления из бэкапов. Полностью поддерживается во всех решениях.

3. Bit Rot Protection (защита от порчи данных)

Что дает: система автоматически проверяет, не испортились ли данные на диске со временем (например, из-за физических дефектов носителя). В корпоративных хранилищах с многолетним хранением данных это критично — мы не можем позволить себе "молчаливую" порчу датасетов, на которые опираются бизнес-решения. MinIO использует алгоритм HighwayHash, SeaweedFS и RustFS также имеют встроенные механизмы проверки целостности. Есть во всех решениях. Базовая функция надежного хранения.

4. Erasure Coding (избыточное кодирование)

Что дает: технология, при которой объект разбивается на блоки данных и блоки четности, позволяя восстанавливать данные при потере до половины дисков в кластере. Это основа отказоустойчивости любого распределенного хранилища. Для нас это означает, что мы можем терять диски без остановки сервиса и без потери данных — очень критично для production-среды. MinIO — erasure coding лежит в основе архитектуры. SeaweedFS поддерживает EC в открытой версии. RustFS — аналогично.

5. Событийная модель / Webhooks

Что даёт: автоматическая реакция на изменения в хранилище — запуск пайплайна, уведомление внешней системы.

У кого есть:

Закрома: HTTP-вебхуки (методы POST/PUT/GET, протоколы HTTP/HTTPS) с аутентификацией BASIC/API_KEY/BEARER_TOKEN. Важное условие: для работы механизма необходима предварительная настройка Kafka в инфраструктуре. Поддерживается настройка как на уровне всего хранилища, так и на уровне бакета.

MinIO: Webhook, Kafka, AMQP (RabbitMQ), MQTT, NATS, NSQ, Elasticsearch и др.

SeaweedFS: доставка через внешние брокеры (RabbitMQ, Kafka).

RustFS: Webhook, Kafka, MQTT, NATS, AMQP, Redis, MySQL/PostgreSQL, Pulsar

Закрома реализует именно HTTP-вебхуки как целевой сценарий (аналогично MinIO и RustFS), но архитектурно зависит от наличия Kafka — это отличает её от MinIO, где Kafka является лишь одной из опций доставки, а не обязательным компонентом.

6. OIDC-интеграция (Keycloak, LDAP/AD, SSO)

Что дает: возможность входа по корпоративной учетной записи и централизованное управление доступом. В Россельхозбанке это обязательное требование безопасности — мы не можем заводить отдельных пользователей в каждом сервисе. MinIO — полная поддержка OIDC и AD/LDAP. SeaweedFS — поддерживает OIDC (включая Keycloak). RustFS — поддержка OIDC реализована, интеграция с AD дорабатывается. В Закрома присутствует поддержка AD/LDAP, OIDC, Keycloak. Итог: есть или частично есть во всех решениях.

7. Аудит действий пользователей и администраторов

Что дает: логирование всех действий для безопасности. В банковском секторе это строгое требование регуляторов — мы обязаны знать, кто, когда и что делал с данными. В Закрома есть возможность настройки аудируемых событий, выгрузка в формате CEF в syslog, есть возможность форматировать аудит-логи для различных SIEM. MinIO и SeaweedFS поддерживают аудит в полном объеме. RustFS — есть журналы сервисов, единый enterprise-уровень audit trail в платной версии. Есть в двух из трех open-source решений.

Масштабирование

Отдельно оценили, как системы растут под нагрузкой.

Закрома предлагает наиболее сложную архитектуру — система состоит из нескольких независимых слоев (метаданные, событийная шина, управляющий слой + слой хранения zds), каждый из которых масштабируется отдельно.Это дает гибкость, но требует более глубокого понимания системы при планировании роста.

RustFS для продакшн-сред выполняется в режиме Multiple Node Multiple Disk (MNMD). Процесс подразумевает добавление новых узлов в кластер. Поддерживается Active-Active репликация на уровне бакетов между несколькими площадками (Multi-Site).

SeaweedFS масштабируется добавлением Volume-серверов, хранящих данные и опционально Master-серверов для метаданных. Однако здесь есть важные особенности: нет автоматической перебалансировки — после добавления новых Volume-серверов данные не перераспределяются автоматически, новые данные пишутся на новые серверы. Для Multi-DC конфигураций нужно создавать новый кластер — переключить существующий Single-DC кластер невозможно.

Для наших задач наиболее понятным оказался подход RustFS, наиболее сложным — Закромы, а SeaweedFS требует внимания к нюансам с перебалансировкой.

Миграция с MinIO

Оценили сложность перехода с MinIO на каждое из решений.

Закрома предлагает встроенный механизм "бесшовной миграции" с внешних S3-хранилищ, позволяющий перевести клиентов на новое хранилище с минимальным простоем (15–30 минут).

RustFS позволяет выполнить миграцию с минимальными изменениями в приложениях — он полностью совместим с S3 и может выступать в роли "бесшовной замены". Самый простой способ — заменить бинарный файл MinIO на RustFS.

SeaweedFS требует полноценного переноса данных с использованием инструментов синхронизации, поскольку это полноценный переезд между системами, а не замена бинарного файла. Рекомендуемый инструмент — rclone.

По итогам двух этапов тестирования мы не получили единственного правильного ответа – у каждого решения свои сильные и слабые стороны. Выбор зависит от ваших приоритетов.

SeaweedFS – идеальный выбор для сценариев с высокими требованиями к скорости чтения (аналитика, ML, работа с большими данными). Зрелый, стабильный, но сложный в администрировании и поддержке продукт. Требует привыкания к управлению ролями через Keycloak, нет автоматической перебалансировки.

RustFS – максимально близок к базовому MinIO по управлению, прост в миграции, показывает отличную скорость записи на средних объемах. Главный риск – молодость продукта и вопросы к отказоустойчивости (ошибка кворума).

Закрома — это не "галочка" для отчетности по импортозамещению, а полноценное энтепрайз-решение с определенными архитектурными особенностями. Да, на текущий момент оно уступает открытым аналогам по сырым скоростным показателям, а многослойная архитектура приводит к заметному отставанию в операциях удаления больших файлов (9 секунд против 0.05–0.08 у конкурентов). Но для нас есть несколько весомых аргументов в его пользу:

• Вендор открыто признает отставание — в ходе обсуждения результатов первого этапа они подтвердили разницу в 15–25% и назвали конкретные планы по оптимизации в ближайших релизах. Мы видим дорожную карту и понимаем, когда и какие улучшения придут.
• ПО с поддержкой — в отличие от опенсорс-решений, здесь есть поддержка 24/7, SLA с гарантированным временем реакции, возможность оперативно получать исправления критических багов. Для нас это важно: очень часто мы не можем ждать, пока комьюнити предложит фикс.
• Влияние на дорожную карту — как корпоративный заказчик мы можем напрямую влиять на развитие продукта. Если нам критична SSE-C или полноценная поддержка STS-токенов, то вендор готов включить эти доработки в ближайшие релизы. В опенсорс-решениях мы просто потребители — наши потребности не являются приоритетом для разработчиков.
• Включение в Единый реестр российского ПО — да, это важный фактор, но не единственный. Для нас критична не столько "бумажная" совместимость, сколько гарантии того, что продукт будет развиваться с учетом наших потребностей.
• Экономическая целесообразность и закрытие рисков — поддерживать собственное open-source решение в условиях жесткой экономии ресурсов — риск. Когда в опенсорс-проекте возникает критический баг, его устранение может занять дни или недели, а в это время продуктивная среда простаивает. С Закромой мы получаем предсказуемый TCO: платим за лицензию и получаем поддержку, обновления, исправления безопасности в рамках контракта, закрываем регуляторные риски (ФЗ-188, требования к ПО из ЕРРП). Конечно, она не отменяет необходимость в собственном SRE — как поддержка Postgres Pro не отменяет DBA. Она даёт предсказуемый SLA, доступ к экспертам вендора и приоритетные исправления, но эксплуатационная ответственность остаётся на заказчике.

Для нас Закрома остается в шорт-листе как кандидат при условии, что поддержка STS-токенов и шифрования будет в скором времени реализована. Однако, если максимальная производительность — это был бы единственный критерий, то выбор пал бы на SeaweedFS или RustFS.

Будем рады услышать ваш опыт в комментариях. Может быть, вы уже эксплуатируете что-то из этого списка в проде? Или тестировали другие решения? Давайте обсудим.