Tantor SE 2024 + PostgreSQL 17 + сертификат ФСТЭК: планируем переход с Postgres Pro 15 для КИИ

Два дня назад PostgreSQL 17 вышел в GA, и буквально следом - новость от Tantor: сертификат ФСТЭК обновлён, Tantor SE 2024 официально подтверждён как СУБД для значимых объектов КИИ уже на PostgreSQL 17. Совпадение по времени приятное, хотя понятно, что готовили заранее.

Для нас это прямое действие: несколько клиентов-субъектов КИИ сидят на Postgres Pro 15, дедлайн по импортозамещению никто не отменял, и вопрос «на что именно переходить» до сегодняшнего дня был открытым. Tantor с актуальным сертификатом - это уже конкретный ответ, а не «ждём документов».

Почему сертификат - не формальность

В регулируемом контуре можно поставить любой PostgreSQL и он будет работать. Вопрос в другом: пройдёт ли он проверку ФСТЭК как элемент защищённой информационной системы на значимом объекте КИИ. Сертификат соответствия по требованиям безопасности информации - это не просто бумага, это условие для включения СУБД в реестр ПО объекта и, соответственно, в отчёт об импортозамещении.

Postgres Pro тоже имеет сертификат, но под 15-ю версию. Обновление сертификата - процесс небыстрый и не параллельный с разработкой, поэтому сейчас картина такая: Tantor SE 2024 сертифицирован на PG 17, Postgres Pro - пока на PG 15. Если клиент хочет мигрировать на PG 17 и остаться в сертифицированном контуре, Tantor - единственный вариант на сегодня.

Сравниваем лицензионные условия

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

Postgres Pro Enterprise лицензируется на ядро или на сервер в зависимости от редакции и числа CPU. Поддержка включена в подписку, уровень SLA зависит от тарифа. Для крупных инсталляций с многопроцессорными серверами стоимость может быть ощутимой.

Tantor SE работает по подписке на инсталляцию. Ценовая модель менее публична - Tantor не публикует прайс открыто, нужно запрашивать коммерческое предложение под конкретную конфигурацию. По нашему опыту работы с несколькими клиентами: на небольших инсталляциях (1-3 сервера) Tantor зачастую выгоднее, на крупных кластерах разница нивелируется.

Важный нюанс: при переходе с Postgres Pro клиент теряет накопленную историю с вендором - какие-то специфические патчи Postgres Pro, расширения из их экосистемы, накопленные тикеты поддержки. Это не катастрофа, но при оценке TCO нужно закладывать время на адаптацию команды к новому вендору.

Поддержка: что реально важно для КИИ

Регулятор требует не просто наличия поддержки, а поддержки от российского вендора с SLA. Оба продукта это закрывают. Разница - в деталях.

Время реакции и глубина. Postgres Pro исторически имеет более зрелую экосистему поддержки - они на рынке дольше, у них больше специалистов с глубокой экспертизой по PostgreSQL internals. Tantor моложе, но команда у них компетентная, и по нашим кейсам критические инциденты закрывались в разумные сроки.

Патчинг. Оба вендора выпускают security-патчи на основе upstream PostgreSQL. Для КИИ-контуров это критично: должны быть регулярные обновления с подтверждёнными CVE-исправлениями. Tantor пока не накопил такой истории, как Postgres Pro, но и PG 17 - свежая база, так что стартовые условия одинаковые.

Документация на русском. У обоих есть, у Postgres Pro она чуть полнее по breadth - больше лет наполнения. Критичного значения не имеет, но при переобучении команды - фактор.

Совместимость с 1С Предприятие

Это отдельный вопрос, который всплывает в половине КИИ-проектов - 1С тут реально болезненная тема.

1С Предприятие сертифицирована под конкретные версии PostgreSQL через собственный сертифицированный патч. Исторически 1С работала в связке с Postgres Pro: там патч встроен в дистрибутив, совместимость гарантирована вендором.

С Tantor SE ситуация чуть сложнее. Tantor также содержит патч для 1С совместимости, и официально заявляет поддержку 1С Предприятие. Но наша практика говорит: перед тем как переводить 1С-базы на Tantor, нужно пройти цикл тестирования на staging, особенно если используются нестандартные конфигурации или самописные расширения. Там всплывают тонкости - например, поведение блокировок под нагрузкой 1С, совместимость конкретной версии платформы с конкретным минорным релизом Tantor.

Мы сейчас как раз проходим этот цикл с одним клиентом: основная аналитическая PostgreSQL-база - без 1С, там переход чистый. А вот 1С-базу выносим в отдельный трек с полным функциональным тестированием перед переключением.

Как выглядит план перехода

Мы оформили его в три фазы для типовой КИИ-инсталляции Postgres Pro 15.

Фаза 1 - аудит и подготовка (2-3 недели). Инвентаризация всех инсталляций Postgres Pro 15 по объектам КИИ, категоризация баз (критичность, наличие 1С, расширения, объём). Сверка с отчётом об импортозамещении - фиксируем что идёт в реестр Minprom вместо Postgres Pro. Проверка совместимости расширений: pg_partman, pg_cron, PostGIS, timescaledb - всё нужно проверить под Tantor SE 2024.

Фаза 2 - миграция некритичных баз (4-6 недель). Поднимаем Tantor SE 2024 на dev и staging. Прогоняем pg_upgrade --link с Postgres Pro 15 - это работает, мы проверяли, но нюансы с кастомными параметрами Postgres Pro есть. Переключаем некритичные production-базы по одной с откатным планом.

Фаза 3 - продуктивные и 1С-базы. Здесь темп медленнее. Для 1С - полное функциональное тестирование на staging-копии реальных данных, потом переключение в согласованное окно. Документируем переход для ФСТЭК: новая СУБД в реестре ПО объекта, актуальный сертификат Tantor SE 2024 прикладываем к пакету документов.

Где сейчас

Первый клиент уже в фазе 1 - инвентаризация завершена, по двум объектам КИИ картина понятна. Второй клиент наблюдает, ждёт наших результатов. Понятно, что план выше - это рамка, а не гарантия: реальные нюансы всегда вылезают в фазе 2 при первом pg_upgrade.

Если вам нужна помощь с аудитом текущего состояния PostgreSQL-инсталляций в КИИ-контуре и оценкой реалистичности перехода на Tantor SE до конца года - напишите, поможем разобраться с конкретной ситуацией.