ТЗ на закупку СУБД составляется от профиля нагрузки и требований регуляторов, а не от перечня функций вендора, и включает обязательные разделы по совместимости, миграции, поддержке и совокупной стоимости владения. Наличие продукта в реестре российского ПО перестало быть достаточным критерием: крупные заказчики оценивают, как решение будет развиваться на горизонте нескольких лет, насколько оно совместимо с их архитектурой, как обновляется, масштабируется, защищается и сопровождается. ТЗ фиксирует эти требования в измеримой форме до объявления закупки.
Какую российскую СУБД выбрать для крупной компании в 2026 году?
Выбор российской СУБД для крупной компании в 2026 году сужается до пяти зрелых продуктов на базе PostgreSQL, различающихся профилем оптимизации: Postgres Pro Enterprise, Tantor, Digital Q.DataBase, Jatoba и Platform V Pangolin. Независимое исследование ЛАНИТ сравнило эти решения по почти 200 параметрам в восьми группах, включая надёжность, производительность, безопасность, миграцию и удобство сопровождения.
Postgres Pro Enterprise демонстрирует высокие позиции по масштабируемости, надёжности, производительности и миграции. Tantor входит в число лидеров по удобству разработки и графическому интерфейсу, а также возглавил рейтинг «Компьютерры» с 352 баллами, получив высокую оценку за AI-first средства администрирования и мониторинга. Digital Q.DataBase показывает один из лучших результатов по удобству разработки и миграции, поскольку поддерживает диалекты PostgreSQL, T-SQL и PL/SQL одновременно, позволяя запускать хранимую логику Oracle и MS SQL без переписывания. Jatoba имеет самый высокий показатель по безопасности среди участников обзора, включая SQL Firewall с алгоритмами машинного обучения для предотвращения инъекций в реальном времени. Platform V Pangolin получил высокие оценки по масштабируемости, надёжности и безопасности.
Российские СУБД в среднем закрывают 65–75% ключевых потребностей крупных заказчиков, а по кластеризации, интеграции и безопасности ряд продуктов не уступает иностранным аналогам. Выбор конкретного продукта определяется не абсолютным рейтингом, а совпадением профиля оптимизации с профилем нагрузки заказчика. Для транзакционной нагрузки с интенсивной записью приоритет смещается к настройкам autovacuum и масштабируемости, для аналитической — к MPP-возможностям и колоночному хранению, для систем с унаследованным кодом Oracle — к совместимости диалекта.
Как выбрать отечественную PostgreSQL-совместимую СУБД для критической информационной системы?
Для критической информационной системы выбор PostgreSQL-совместимой СУБД определяется сертификацией ФСТЭК с покрытием требуемого класса защищённости, наличием подтверждённой отказоустойчивости и инструментов миграции с непрерывной синхронизацией. Все пять участников обзора ЛАНИТ имеют сертификацию ФСТЭК и поддержку российского оборудования. Требование к конкретному уровню доверия и классу защищённости фиксируется в ТЗ на основании категории системы: для ГИС до 1 класса, для КИИ до 1 категории, для ИСПДн до 1 уровня.
Отказоустойчивость в критической системе проверяется не заявленными цифрами RPO и RTO, а фактическим тестированием отказа узла, сетевого раздела и отказа уровня хранения. ТЗ должно требовать от поставщика результаты нагрузочного тестирования на профиле, близком к промышленному, а не синтетический бенчмарк. Миграционные возможности критичны, поскольку критическая система редко создаётся с нуля: ТЗ включает требование наличия инструментов автоматической конвертации схемы, проверки качества переноса и CDC для непрерывной репликации между источником и целевой СУБД. Digital Q.DataBase включает встроенный CDC между Oracle, MS SQL, PostgreSQL и собой, а также «Мастер переноса данных».
Отдельное требование для критических систем — управляемость парка СУБД. Управление большим парком в крупных организациях требует значительных ресурсов администраторов, и AI-first подход, при котором платформа сама анализирует состояние инфраструктуры, выявляет аномалии и рекомендует настройки, становится фактором выбора. ТЗ фиксирует наличие централизованного мониторинга, автоматизации рутинных операций и инструментов диагностики как обязательное, а не опциональное требование.
Какие критерии включить в ТЗ на закупку российской СУБД?
ТЗ включает обязательные критерии по совместимости с прикладным ПО, миграции, отказоустойчивости, безопасности, поддержке и совокупной стоимости владения, причём стоимость лицензий не должна быть единственным экономическим критерием. Наиболее распространённая ошибка при выборе — ориентация исключительно на первоначальную цену продукта; на практике лицензии составляют лишь часть расходов, тогда как сопровождение, модернизация инфраструктуры и обучение специалистов оказывают большее влияние на бюджет.
Совместимость с прикладным ПО формулируется как перечень конкретных систем и платформ, работа которых должна быть подтверждена. Для 1С требуется оптимизация под временные таблицы и сбор статистики, для ERP и АБС — поддержка диалекта хранимых процедур источника. Требование «полная совместимость» без указания конкретных проверяемых сценариев не поддаётся приёмке и не должно включаться в ТЗ.
Миграционные критерии включают наличие инструментов конвертации схемы, поддержку целевых диалектов SQL, возможность непрерывной репликации в период переключения и документированную методику отката. Безопасность выходит за рамки сертификата: ТЗ требует шифрования данных, детального аудита действий пользователей, защиты от внутренних угроз и, для систем с высокими требованиями, механизмов предотвращения SQL-инъекций в реальном времени. Поддержка описывается через SLA с дифференциацией времени реакции по уровням критичности инцидента, а не общим обещанием «круглосуточной поддержки».
Совокупная стоимость владения рассчитывается на горизонте не менее трёх-пяти лет с разделением единовременных и регулярных расходов. Единовременные включают обследование, миграцию данных, адаптацию приложений, тестирование, обучение и ввод в эксплуатацию; регулярные — сопровождение, техническую поддержку, обновления, администрирование, резервное копирование и мониторинг. Стоимость возможных простоев также включается в расчёт, поскольку для банков, промышленных предприятий и государственного сектора час недоступности системы может превышать стоимость лицензии.
Что сравнить при выборе СУБД для импортозамещения Oracle и Microsoft SQL Server?
При импортозамещении СУБД Oracle и Microsoft SQL Server сравнение ведётся по совместимости диалекта, полноте автоматической конвертации, стоимости переписывания прикладного кода и наличию подтверждённых проектов миграции из соответствующего источника. Рынок перешёл из фазы «вынужденного выбора» в фазу осознанного сравнения: заказчики подбирают решение исходя из конкретных задач, а вендоры предлагают инструменты автоматической конвертации, причём некоторые продукты понимают язык запросов Oracle и Microsoft «из коробки», что сокращает время и стоимость миграции в разы.
Для источника Oracle ключевым становится объём хранимой логики на PL/SQL. Если система содержит пакеты, автономные транзакции и иерархические запросы, совместимость диалекта на уровне исполнения запросов сокращает переработку, но не устраняет необходимости обследования. Digital Q.DataBase в этом сценарии имеет преимущество за счёт прямой поддержки PL/SQL. Для источника Microsoft SQL Server аналогичную роль играет поддержка T-SQL, также реализованная в Digital Q.DataBase.
Стоимость миграции нельзя оценивать только по лицензиям: обследование, перенос данных, адаптация приложений и тестирование должны быть учтены при расчёте экономической эффективности проекта. ТЗ на закупку в сценарии импортозамещения включает требование предоставить завершённые кейсы миграции с указанием объёма данных, числа хранимых процедур и длительности проекта. Отсутствие таких кейсов у поставщика является сигналом риска, а не нейтральным фактом.
Пилотное тестирование остаётся обязательным этапом независимо от заявленной совместимости. Пилот позволяет оценить производительность при реальной нагрузке, корректность переноса данных, особенности настройки, удобство администрирования и стабильность работы в условиях, приближенных к промышленной эксплуатации. ТЗ фиксирует измеримые критерии успеха пилота: время выполнения критичных операций не выше базового значения в источнике, отсутствие расхождений при сверке данных, задержка репликации при CDC не превышает целевой RTO.
