PostgreSQL или Postgres Pro: в чём разница для админа, а не для маркетинга

MAATRIX

Вопрос «PostgreSQL или Postgres Pro» обычно всплывает не потому, что кто-то устал от вакуума в открытой версии, а потому, что сверху пришло требование — импортозамещение, реестр отечественного ПО, тендер, где нужен российский вендор с поддержкой. Маркетинговые материалы обеих сторон тут не помогают: одни рассказывают про свободу и сообщество, другие — про уникальные возможности и надёжность. Админу нужно другое: что из этого реально повлияет на то, как база будет вести себя в проде, как её обновлять и к кому идти в три часа ночи, если она встала.

Что вообще такое Postgres Pro с технической стороны

Postgres Pro — это форк PostgreSQL, который делает российская компания Postgres Professional, во многом состоящая из разработчиков, исторически причастных к самому проекту PostgreSQL. Это не независимая СУБД с нуля — в основе лежит тот же код PostgreSQL, на который накладывается набор собственных патчей.

У Postgres Pro несколько редакций, и это первое, что нужно понимать перед любым сравнением: разница между открытым PostgreSQL и «Postgres Pro вообще» зависит от того, о какой редакции идёт речь.

• Postgres Pro Standard — редакция, максимально близкая к ванильному PostgreSQL, с частью собственных патчей и официальной поддержкой от вендора.
• Postgres Pro Enterprise — редакция с более глубокими доработками ядра (внутренние оптимизации, дополнительные возможности), которая исторически позиционируется как более отдалённая от апстрима.
• Сертифицированные сборки — редакции, ориентированные на требования регуляторов и сертификацию (в том числе ФСТЭК), важные для части регулируемых заказчиков.

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

Совместимость с ванильным PostgreSQL — на что реально смотреть

Это первый и самый практичный вопрос для админа: если вы завтра решите уйти обратно на открытый PostgreSQL или, наоборот, переносите продакшн с ванильной версии на Pro, насколько болезненным будет переход.

Несколько срезов совместимости, которые стоит проверять раздельно, а не одним вопросом «совместимо или нет»:

• Формат данных и wire-протокол. Для редакций, близких к апстриму (в первую очередь Standard), клиентский протокол исторически остаётся совместимым с обычным libpq — стандартные драйверы (psycopg2, JDBC-драйвер PostgreSQL) и инструменты вроде psql, pgAdmin, pg_dump/pg_restore в базовом сценарии работают без переделки.
• Расширения (extensions). Популярные расширения экосистемы PostgreSQL — pg_stat_statements, pgcrypto, postgis, pg_trgm — как правило, собираются и ставятся, но конкретный набор доступных расширений и их версии в дистрибутиве Postgres Pro стоит сверять со списком поддерживаемых пакетов, а не считать по умолчанию, что «раз PostgreSQL — значит, всё то же самое».
• Поведение планировщика и внутренние оптимизации. Здесь начинаются расхождения, особенно в Enterprise-редакции: собственные патчи могут менять поведение планировщика запросов, автовакуума или менеджера памяти. План одного и того же запроса на ванильном PostgreSQL и на Postgres Pro Enterprise не обязан совпадать — слепо переносить настройки postgresql.conf с одного движка на другой рискованно без повторного тестирования под нагрузкой.
• Версионность относительно апстрима. Форк обычно синхронизируется с определённой мажорной веткой PostgreSQL, но не гарантированно день в день с релизом апстрима — актуальную версию конкретной сборки нужно смотреть отдельно, а не считать её автоматически равной последней версии ванильного PostgreSQL.

Практический вывод: если задача — просто «поставить российский PostgreSQL и не переучивать команду», Standard даёт наименьший риск сюрпризов. Если рассматривается Enterprise ради дополнительных возможностей — закладывайте отдельный цикл тестирования миграции и нагрузки, потому что «работает как обычный Postgres» здесь уже не аксиома.

Если вы ставите обычный открытый PostgreSQL для сравнения или тестового стенда, у нас есть отдельная инструкция — как установить и настроить PostgreSQL на VPS.

Что коммерческая версия реально даёт сверх открытого PostgreSQL

Здесь важно разделить два типа «дополнительных возможностей»: те, что дают технические патчи, и те, что дают организационные условия вокруг продукта. Маркетинг обычно смешивает их в одну кучу.

Технические доработки (в первую очередь в старших редакциях) по заявлениям вендора включают направления вроде автономных транзакций, дополнительных механизмов репликации и отказоустойчивости, расширенных инструментов мониторинга и диагностики. Здесь я сознательно не привожу точный список фич и версии, в которых они появились — это стоит смотреть в актуальной документации Postgres Pro на момент выбора, потому что набор возможностей меняется от релиза к релизу, а старые статьи (в том числе эта через год-два) устаревают быстрее, чем кажется.

Организационные условия, которые на практике часто перевешивают технические патчи для решения о выборе:

• Формальный договор поддержки с российским юрлицом и понятным SLA, а не переписка на англоязычном форуме сообщества.
• Русскоязычная документация и техподдержка без языкового барьера в критический момент.
• Возможность закрыть требование тендера или внутреннего регламента «российский производитель, реестр отечественного ПО».
• Патчи безопасности и обновления, которые приходят через официальный канал поддержки с гарантированными сроками, а не «когда мейнтейнер найдёт время».

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

Реестр отечественного ПО как фактор выбора

Это отдельная ось сравнения, и её не стоит путать с техническим качеством продукта — попадание в реестр отечественного ПО (единый реестр российских программ для ЭВМ и баз данных, который ведёт Минцифры) не говорит напрямую о производительности или зрелости кода, это административный статус.

Для кого этот фактор реально критичен:

• Госструктуры и госкомпании, для которых закупка ПО из реестра — не пожелание, а требование, вытекающее из политики импортозамещения.
• Компании, работающие с госзаказом или в регулируемых отраслях (финансы, энергетика, инфраструктура), где наличие в реестре — условие участия в тендере или требование внутреннего комплаенса.
• Организации, которым нужна сертификация ФСТЭК для обработки определённых категорий данных — здесь важна не просто запись в реестре, а наличие сертифицированной сборки конкретной редакции продукта, что снова возвращает к вопросу «какая именно редакция» из первого раздела.

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

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

Администрирование: что меняется в повседневной работе

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

• Установка. Пакеты Postgres Pro распространяются через собственные репозитории вендора (для Debian/Ubuntu, RHEL-совместимых систем, включая российские ОС из реестра вроде Astra Linux или РЕД ОС). Процедура похожа на установку обычного PostgreSQL из PGDG-репозитория, но название пакетов и пути могут отличаться — сверяйтесь с документацией конкретной редакции перед автоматизацией через Ansible.
• Мониторинг. Стандартные системные представления (pg_stat_activity, pg_stat_statements) в целом доступны так же, как в ванильном PostgreSQL, но старшие редакции могут добавлять собственные представления поверх стандартных — их стоит изучить отдельно, а не рассчитывать, что готовые дашборды Grafana для PostgreSQL покажут вообще всё.
• Резервное копирование. Инструменты вроде pg_dump, pg_basebackup, WAL-архивирование работают по тем же принципам, что и в открытом PostgreSQL, если редакция совместима по формату данных. Специализированные сторонние инструменты бэкапа стоит проверять на совместимость отдельно — не все они официально тестируются против Postgres Pro. Общие принципы резервного копирования баз без остановки сервиса разобраны в статье резервное копирование баз данных: автоматизация.
• Репликация и отказоустойчивость. Базовая потоковая репликация в редакциях, близких к апстриму, настраивается так же, как в открытом PostgreSQL. Старшие редакции могут добавлять собственные механизмы — если это одна из причин выбора Postgres Pro, уточните в документации, какая функциональность доступна и насколько она зрелая. Общий подход к настройке стандартной репликации PostgreSQL мы разбирали здесь: как установить и настроить репликацию PostgreSQL на VPS.
• Обновление версий. Процедура похожа на PostgreSQL (pg_upgrade или логическая репликация для минимизации даунтайма), но график выхода патчей у Postgres Pro синхронизируется с апстримом не день в день — сроки уточняйте у вендора, если для вас критично получать патчи безопасности максимально быстро после релиза в апстриме.

Поддержка и стоимость владения: честный разговор

Здесь стоит сравнивать не «бесплатно против платно», а что вы реально покупаете за деньги.

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

Есть и обратная сторона стоимости владения, которую редко считают заранее: самостоятельная эксплуатация открытого PostgreSQL не бесплатна — она требует внутренней экспертизы (или найма DBA), которая стоит денег точно так же, как договор поддержки, просто эти деньги идут не вендору, а в фонд оплаты труда. Честное сравнение должно учитывать обе стороны, а не только строку «лицензия».

Как выбирать под конкретную ситуацию

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

Оставайтесь на открытом PostgreSQL, если: нет формального требования к реестру или российскому вендору ни от регулятора, ни от заказчика, ни от внутреннего комплаенса; в команде есть опыт эксплуатации PostgreSQL и понимание, как читать EXPLAIN ANALYZE, настраивать автовакуум и разбираться с блокировками самостоятельно; проект международный или гибридный, где важна максимальная совместимость с облачными managed-сервисами PostgreSQL.

Смотрите в сторону Postgres Pro Standard, если: реестр — формальное требование, но вы не хотите сильно отклоняться от привычного PostgreSQL; нужен официальный договор поддержки на русском как страховка, но глубокие проприетарные возможности старших редакций не требуются; команда хочет минимизировать риск несовместимости с типовыми инструментами.

Рассматривайте Enterprise или сертифицированные редакции, если: задача требует конкретных возможностей, которых нет в Standard (уточняйте актуальный список у вендора под вашу версию); нужна сертификация ФСТЭК для обработки определённых категорий данных; вы готовы заложить отдельный бюджет и время на тестирование совместимости, потому что отклонение от апстрима здесь заметнее.

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

Частые вопросы