При выборе российской СУБД следует исходить из класса критичности системы, а не из рейтинга производительности продуктов. Для объектов КИИ и государственных информационных систем сертификация ФСТЭК — это условие допуска, а не дополнительное преимущество; для обычных корпоративных систем зрелого дистрибутива на базе PostgreSQL с коммерческой поддержкой достаточно для большинства задач. Ниже приведена матрица оценки, позволяющая принимать решение на стыке требований регуляторов, технической совместимости и совокупной стоимости владения.
Когда необходима корпоративная российская СУБД, а когда достаточно открытой версии PostgreSQL
Корпоративная российская СУБД необходима тогда, когда система отнесена к объектам КИИ, обрабатывает государственную тайну или персональные данные, подлежит сертификации ФСТЭК, а простой измеряется недопустимыми потерями. Во всех остальных случаях открытая версия PostgreSQL с поддержкой по SLA обходится дешевле.
Законодательство устанавливает конкретные сроки перехода. По планам Минцифры большинство объектов КИИ должны завершить миграцию на отечественное ПО и программно-аппаратные комплексы до 1 января 2028 года, а часть сложных проектов — до 1 декабря 2030 года. Целевой показатель — перевод 80% предприятий ключевых отраслей на российское ПО к 2030 году. Издержки несоблюдения растут: регулятор рассматривает ежегодные оборотные штрафы для предприятий, не завершивших категорирование и миграцию в срок.
Признаки критически важной системы: простой напрямую влияет на выручку, обрабатываемые данные относятся к регулируемым категориям, система классифицирована как объект КИИ или ГИС. В этих условиях установка базовой версии PostgreSQL не обеспечивает соблюдение юридических требований, поскольку сертификация ФСТЭК выдаётся на конкретную версию продукта, а базовые сборки такого статуса не имеют.
Для систем вне перечисленных категорий — внутренние инструменты управления проектами, среды разработки и тестирования, неключевая отчётность — критерием становится технико-экономическая целесообразность: открытая версия PostgreSQL обладает самой широкой документацией и пулом специалистов, а ценность коммерческого дистрибутива состоит в предсказуемом времени реакции поддержки и усиленной сборке. По данным рыночного исследования 2025 года, российские СУБД в среднем покрывают 65–75% ключевых требований крупных заказчиков, а по кластеризации, интеграции и безопасности отдельные продукты не уступают зарубежным аналогам.
Матрица оценки: десять обязательных технических и регуляторных критериев
Матрица должна охватывать три группы критериев — соответствие обязательным требованиям, функциональную пригодность и экономику эксплуатации; решающее значение в ней имеют сертификация ФСТЭК и совместимость SQL-диалектов. Перечисленные ниже критерии образуют применимый на практике оценочный лист.
Регуляторные критерии — первый фильтр. Проверяется наличие продукта в едином реестре российского ПО, действующий сертификат ФСТЭК, соответствие охваченных уровней защиты и доверия классу системы. Например, «РЕД База Данных» имеет сертификат ФСТЭК и применима до I класса защищённости ГИС, до I уровня защищённости ИСПДн, до I категории КИИ и до I класса АСУ ТП. Сертификация сама по себе не гарантирует безопасность, но без неё критически важная система не имеет юридических оснований для эксплуатации.
Техническая совместимость определяет выполнимость миграции и совокупную стоимость владения. Ключевая метрика — поддержка SQL-диалектов: если система использует хранимые процедуры PL/SQL от Oracle или T-SQL от Microsoft, от совместимости напрямую зависит, придётся ли переписывать миллионы строк бизнес-логики. Digital Q.DataBase поддерживает диалекты PostgreSQL, T-SQL и PL/SQL, позволяя приложениям подключаться через нативные протоколы и библиотеки. Для работающих банковских и ERP-систем это даёт заметную экономию на миграции.
Производительность и архитектура должны соответствовать типу нагрузки. Транзакционная нагрузка (OLTP) требует высокой пропускной способности, большого числа одновременных соединений и эффективных блокировок; аналитическая (OLAP) — MPP-архитектуры, колоночного хранения и сжатия. Tantor Postgres и Postgres Pro Enterprise эффективны в транзакционных и смешанных нагрузках.
Высокая доступность и аварийное восстановление выражаются в целевых RPO и RTO. Поддерживаются ли синхронная репликация, автоматическое переключение, межцентровая репликация? Для объектов КИИ способность автоматически распределять данные между ЦОД напрямую влияет на прохождение аттестации.
Безопасность не ограничивается сертификатом. Проверяются встроенное маскирование данных, динамическое скрытие полей, целостность журналов аудита, модель разделения ролей и интеграция с внешними SIEM. Связка Jatoba и Dallas Lock позволяет работать в доверенной среде и, по заявлениям, сокращает число компенсирующих мер. Для систем персональных данных такие интеграции укорачивают цикл аттестации.
Инструменты миграции часто недооцениваются, хотя прямо определяют срок проекта. Предлагаются ли автоматическая конвертация схем, сверка данных и захват изменений из Oracle, MS SQL, PostgreSQL? Digital Q.DataBase включает CDC между Oracle, MS SQL, PostgreSQL и собой. Отсутствие средств миграции перекладывает расходы на интегратора.
Экономика эксплуатации включает модель лицензирования, требования к оборудованию и доступность компетенций. Версии на базе PostgreSQL допускают использование стандартных x86-серверов вместо специализированных комплексов, снижая затраты на оборудование и риски поставок. Что касается кадров, специалистов по экосистеме PostgreSQL на рынке труда заметно больше, чем по проприетарным СУБД.
Мониторинг и наблюдаемость влияют на среднее время восстановления. Есть ли графический центр управления, трассировка запросов, прогноз роста и оповещения? Веб-центр Digital Q.DataBase включает PITR-резервное копирование, трассировку запросов и настройку кластера. Tantor Postgres содержит средства управления и мониторинга на основе искусственного интеллекта для автоматизации рутинных задач и поиска узких мест. Недостаточная наблюдаемость промышленной эксплуатации — основной источник скрытых издержек простоя.
Соответствие сценариям: приоритеты выбора для разных систем
Для 1С и ERP приоритет — совместимость диалектов, оптимизация временных таблиц и сертифицированная оптимизация под 1С, а не универсальный рейтинг производительности. Специализированный рейтинг CNewsMarket ставит Tantor Postgres for 1C на первое место, а Postgres Pro Enterprise for 1C — следом. Эти версии оптимизированы под специфику временных таблиц 1С, сбор статистики и построение планов запросов. Игнорирование этого уровня адаптации при выборе универсальной СУБД обычно приводит к дорогостоящей настройке на уровне приложения.
Банковские и финансовые системы ограничены целостностью транзакций, аудиторским следом и охватом сертификата ФСТЭК для финансовых данных. Такие системы требуют принципа четырёх глаз, гранулярного контроля доступа и неизменяемых журналов аудита. При выборе конкретный охват сертификата ФСТЭК важнее общих заявлений о безопасности. Одновременно стоимость миграции существующих хранимых процедур Oracle следует оценить заранее — поддержка диалекта PL/SQL сжимает срок с месяцев до недель.
Промышленная автоматизация и АСУ ТП требуют работы СУБД на ограниченном оборудовании, поддержки записи в реальном или близком к реальному времени и интеграции с уровнем SCADA. Сертификат ФСТЭК на «РЕД База Данных» до I класса АСУ ТП допускает применение продукта в этой сфере. Для таких систем RTO обычно измеряется секундами, а надёжность синхронной репликации и механизмов heartbeat становится ключевым критерием оценки.
Аналитические платформы и хранилища должны в первую очередь оцениваться по MPP-архитектуре, колоночному хранению и эффективности сжатия.
Системы высокого класса защиты нуждаются в согласованной работе СУБД и подсистемы безопасности операционной системы. Интеграция Jatoba с Dallas Lock призвана обеспечить защиту одновременно на уровне ОС и процессов СУБД, сокращая потребность в компенсирующих мерах при аттестации. Такие связки дают выигрыш по регуляторной эффективности в ОПК и хранилищах чувствительных данных.
Шаблон закупочной документации: перечень вопросов поставщику
До закупки от каждого кандидата следует получить пять категорий проверяемой информации: охват сертификации, результаты нагрузочных испытаний, кейсы миграции, SLA поддержки и детализацию совокупной стоимости. Уклончивый или размытый ответ поставщика сам по себе сигнализирует о риске.
Вопросы по сертификации. Предоставить действующий сертификат ФСТЭК с указанием охваченной версии продукта, уровня защищённости и доверия. Охватывает ли сертификат планируемую к развёртыванию версию или только старую? Если у планируемой версии сертификата нет, какова дорожная карта получения сертификата?
Вопросы по производительности. Предоставить результаты нагрузочных испытаний на целевом типе нагрузки: частота транзакций, число одновременных пользователей, распределение задержек запросов — не только средних, но и P95, P99. На какой конфигурации оборудования проводились тесты и воспроизводимы ли они? Для аналитической нагрузки — результаты TPC-H или TPC-DS.
Вопросы по миграции. Предоставить завершённые кейсы переноса с исходных систем (Oracle, MS SQL, PostgreSQL) с указанием объёма данных, числа хранимых процедур и длительности миграции. Если исходная система использует диалект-специфичные процедуры, стратегия — автотрансляция, ручное переписывание или слой совместимости времени выполнения?
Вопросы по поддержке. Определить в SLA время реакции, различая критический сбой, серьёзную деградацию и общие консультации. Каковы география и языковое покрытие команды поддержки? Предлагается ли опция выделенного инженера на месте?
Вопросы по экономике. Предоставить полную декомпозицию затрат: лицензии (по ядрам, пользователям или серверам), ежегодная доля поддержки, обучение, средства миграции, оценка интеграционных услуг. Есть ли скрытые затраты, связанные с оборудованием? Доступна ли подписка вместо бессрочной лицензии?
Измеримые критерии успеха пилотного проекта
До вывода в промышленную эксплуатацию пилот должен подтвердить пять измеримых показателей: целевой APDEX, RPO, RTO, время выполнения критически важных операций и скорость реакции поддержки. СУБД, не прошедшая проверку по этим метрикам, не должна попадать в закупку для промышленной эксплуатации.
APDEX (индекс производительности приложений) задаётся целевым значением, обычно не ниже 0,94, и измеряется при имитации промышленной нагрузки. Сценарии тестирования должны покрывать пиковые нагрузки, смешанное чтение-запись и снижение производительности после длительной работы. APDEX ниже целевого указывает на прямой риск неудовлетворённости пользователей.
RPO и RTO должны проверяться реальным внесением отказов, а не заявлениями поставщика. Тесты включают отказ главного узла, сетевой раздел и отказ уровня хранения.
Время выполнения критически важных операций измеряется на реальной рабочей нагрузке, собранной в промышленной среде. Цель — выполнить одинаковые операции на исходной системе и на кандидате и сравнить время. Если критически важные операции (закрытие месяца, построение отчётов, пакетная загрузка) замедляются сверх допустимого порога, ценность миграции утрачивается.
Скорость реакции поддержки измеряется фактически в ходе пилота. Подаются запросы разного уровня критичности, фиксируются время первого ответа, время решения и эффективность эскалации. Историческое качество поддержки точнее предсказывает результат, чем пункты договорного SLA.
Показатели пользовательского опыта включают задержку входа, время отрисовки страниц и отклик интерфейса при одновременной работе нескольких пользователей. Даже если эти метрики не отражают напрямую производительность СУБД, они служат итоговым критерием успеха миграции. Если пользователи ощущают замедление, технические преимущества СУБД на уровне организации ценности не создают.