Импортозамещение СУБД: что реально работает вместо MS SQL и Oracle

Тема импортозамещения СУБД всё настойчивее лезет в наши разговоры с клиентами. Правительственная комиссия по импортозамещению ПО активно работает над реестром отечественного программного обеспечения - давление на организации с государственным участием нарастает, и вопросы типа «а что у нас есть вместо MS SQL» из абстрактных быстро становятся конкретными. Мы решили собрать то, что накопилось по итогам нескольких аудитов клиентских инфраструктур за последние месяцы.

Оговоримся сразу: речь не про сравнительные тесты в вакууме, а про реальные инфраструктуры, реальных пользователей и реальные нагрузки. Сферических коней не держим.

PostgreSQL: технически готов, но не из коробки

Это самый интересный кандидат на замену MS SQL для OLTP-нагрузок. Мы уже разворачивали PostgreSQL под 1С 8.3 летом - и вывод не изменился: работает, но требует понимания.

Что работает хорошо:

• OLTP-нагрузки среднего масштаба - при правильно настроенном shared_buffers, work_mem и политике checkpoint производительность сопоставима с MS SQL Express и нижними редакциями SQL Server.
• Совместимость с прикладными системами - 1С 8.3 через специальную сборку, ряд отечественных ERP тоже заявляют поддержку PostgreSQL.
• Репликация и бэкап - streaming replication работает стабильно, pg_dump/pg_basebackup покрывают стандартные сценарии.

Где неудобно:

• Инструменты мониторинга и диагностики - привычного SQL Server Management Studio нет. pg_stat_statements, pgBadger, explain analyze - всё это работает, но требует перестройки операционных привычек у DBA.
• Оконные функции и CTE - поддерживаются, но оптимизатор в ряде случаев ведёт себя иначе. Запросы, которые писались под MS SQL, иногда требуют переработки.
• Квалифицированные руки - PostgreSQL-администраторов меньше, чем MS SQL-администраторов. Пока. Это кадровый риск, который надо учитывать.

Итог по PostgreSQL: для новых проектов и для миграции OLTP-баз среднего размера - реальный вариант. Не «когда-нибудь», а прямо сейчас, если есть ресурс на настройку.

Firebird: небольшие базы 1С, да

Firebird в разговорах про импортозамещение часто упоминают как вариант для 1С. Это правда, но с оговорками. Платформа 1С 8.x поддерживает Firebird как файловый вариант, и для небольших баз - условно до 10-15 активных пользователей - это работает нормально.

Но масштаб критичен. Когда база растёт, когда пользователей становится больше и когда начинается конкуренция за блокировки - Firebird начинает уступать. Архитектурно он не рассчитан на то, что умеет PostgreSQL в части параллелизма и обработки длинных транзакций. Для небольшого офисного учёта или склада без серьёзной аналитики - подходит. Для чего-то большего - надо думать дважды.

Oracle: самый сложный случай

Вот здесь честный ответ неприятен. Замены Oracle, сопоставимой по функциональности, в open source на сегодня нет. Да, есть PostgreSQL - и он закрывает значительную часть задач, которые некоторые клиенты решают на Oracle просто по историческим причинам, а не потому что реально нужны Oracle-специфичные возможности. Таких миграций - с Oracle на PostgreSQL - вполне можно делать.

Но там, где Oracle используется по делу - партиционирование больших таблиц, материализованные представления с fast refresh, Advanced Queuing, специфические особенности оптимизатора при сложных многотабличных запросах - замена требует либо серьёзной переработки приложения, либо принятия функциональных потерь. Зарубежные Enterprise СУБД типа IBM DB2 теоретически ближе по возможностям, но импортозамещением это не назовёшь.

Если клиент сидит на Oracle и ему нужно «импортозаместить прямо сейчас» - честный разговор про это выглядит так: либо PostgreSQL плюс переработка слоя работы с данными, либо откровенный разговор с регулятором о реальных сроках. Быстрых решений здесь нет.

Что мы делаем на практике

Когда к нам приходит задача по СУБД в контексте импортозамещения, первый шаг - инвентаризация: что реально используется, какие функции СУБД задействованы приложением, какой объём данных, какая нагрузка. Это аудит, и без него разговор про «замену Oracle на PostgreSQL» - это разговор в пустоту.

Половина клиентов, которые считали что у них «зависимость от Oracle», после инвентаризации оказывались на функциональности, которую PostgreSQL покрывает без вопросов. Вторая половина - там действительно есть о чём думать.

Реестр отечественного ПО, который сейчас формируется на уровне правительственной комиссии, - это не волшебная таблетка. Включение продукта в реестр не означает, что он заменяет то, что вы используете. Означает лишь что он отечественный. Функциональное соответствие - отдельный вопрос, и его надо задавать отдельно.