PostgreSQL и MS SQL — реальная разница в производительности

2026-05-24 11:42

Открытая база данных от сообщества Постгрес напоминает швейцарский нож с расширениями, а продукт Microsoft — профессиональный инструмент с готовым обвесом. Оба режут, оба считают, но логика выбора в 2026 году изменилась радикально. Западная платформа официально не продается российским заказчикам с 2022 года, объекты КИИ обязаны переехать на ПО из российского реестра Минпромторга, и параллельно с этим отечественная сборка Postgres Pro дозрела до уровня, на котором реальные внедрения 1С:ERP на 100+ пользователей перестали быть подвигом.

Дальше разберем по порядку: где открытый движок медленнее коммерческого аналога, где быстрее, как меняется стоимость владения после миграции и какие подводные камни ждут команду. И главное — с реальными цифрами по TPC-C, бенчмарками pgbench и опытом на 1С через метрику Apdex (Application Performance Index — индекс удовлетворенности пользователя от 0 до 1, где 1 значит, что все запросы отрабатывают мгновенно) от сервиса Gilev.ru.

Почему вокруг этого сравнения столько шума в 2026

Большинство российских заказчиков либо уже мигрировало, либо находится в процессе планирования. И вот почему.

Импортозамещение и реестр Минпромторга

Начнем с регуляторики. Объекты критической информационной инфраструктуры по 187-ФЗ и приказу ФСТЭК № 117 от 11.04.2025 обязаны использовать ПО из российского реестра Минпромторга. Microsoft SQL Server в этом реестре отсутствует и появится там вряд ли. А вот Postgres Pro Standard и Enterprise — зарегистрированы отдельными записями (актуальные номера проверяются на reestr.minpromtorg.gov.ru). Поэтому для госструктур и значимых объектов это уже не вопрос предпочтений, а законодательное требование.

Уход западной СУБД с прайс-листов российских интеграторов

Регуляторика — не единственный драйвер. Корпорация из Редмонда прекратила продажи в стране в 2022 году: действующие лицензии работают, новые официально не выдаются. Software Assurance не продлевается, доступ к серверным обновлениям ограничен. Поддержку продлевают через зарубежные аккаунты — а это уже серая зона по лицензионной чистоте. В итоге большинство интеграторов убрали платформу Редмонда из коммерческих предложений и пересобрали стек на опенсорс.

Готовность 1С, бухгалтерских и ERP-систем к Postgres Pro

Третий драйвер — экосистема. С 2022 года фирма «1С» включила отечественный дистрибутив в список официально рекомендуемых баз. Специальные сборки 1С-варианта Postgres Pro дают сопоставимую с конкурентом рабочую нагрузку на типовых конфигурациях УТ 11, БП, ЗУП, ERP. Аналогично прошли сертификацию модули БИТ.Финанс, ELMA365, 1С-Битрикс и многие ECM-системы. То есть прикладной слой к переезду давно готов.

Архитектурные различия

Под капотом движок и его конкурент устроены по-разному, и понимание этих различий помогает заранее увидеть, где будет узкое место после переноса.

MVCC против блокировок на уровне строк

Открытый движок использует MVCC (Multi-Version Concurrency Control): каждая транзакция видит свою версию данных, читатели не блокируют писателей и наоборот. Цена за это удобство — фоновая работа vacuum, который удаляет устаревшие версии строк. У платформы Редмонда подход иной: по умолчанию работают блокировки на уровне строк (row-level locking) с механизмом READ COMMITTED через блокировки. Уровень isolation snapshot включается отдельно и приближает поведение к MVCC. На практике это выливается в следующее: открытое решение чище ведет себя на длинных читающих транзакциях, а коммерческий аналог — на коротких OLTP с пиковой записью.

Один процесс на соединение против пула потоков

Дальше — модель соединений. Свободный движок создает отдельный процесс ОС на каждое подключение. С одной стороны, это дает изоляцию — упавший процесс не роняет сервер. С другой — требует памяти, потому что каждый процесс ест 5–15 МБ только под структуру. Для сотен подключений нужен pgBouncer или встроенный pool на стороне приложения. Коммерческий конкурент идет другим путем — использует thread pool внутри одного процесса, поэтому соединения у него дешевле. Но под нагрузку 500+ конкурентных коннектов без пулера лучше не выходить ни в одном случае.

Расширения против встроенных модулей

Третье отличие — модель функциональности. Открытая система — это ядро плюс экосистема расширений: PostGIS под геоданные, pg_partman — под партиционирование, pg_vector — под AI-эмбеддинги, TimescaleDB — под time-series, Citus — под шардинг. Все они подключаются через CREATE EXTENSION. Западный продукт устроен противоположно: поставляется монолитом со встроенными функциями — SSIS под ETL, SSAS под OLAP, SSRS под отчетность, Service Broker под очереди, FILESTREAM под BLOB-данные. Подобрать сервер баз данных под нужный стек расширений — отдельная задача, в которой стоит участвовать на этапе проектирования.

OLTP — TPS, latency, конкурентность

От архитектуры переходим к главному вопросу большинства бизнес-приложений: какая система выдержит больше операций в секунду на одном железе.

TPC-C-подобные тесты на типовых нагрузках

Цифры такие. Открытые бенчмарки HammerDB (клон TPC-C) на сопоставимом железе показывают: на 16 ядрах (Xeon Gold 6338, 256 ГБ RAM, NVMe) Microsoft SQL Server 2022 выдает примерно на 10–25% больше TPS, чем PostgreSQL 16 «из коробки». Разница появляется в основном за счет более агрессивного планировщика MS-стека и оптимизации thread pool под высокую конкурентность. Но это «из коробки». После тонкой настройки опенсорса (shared_buffers 25% RAM, work_mem 16–64 МБ, max_parallel_workers по числу ядер, autovacuum_max_workers) разрыв сокращается до 5–15% на большинстве реальных рабочих нагрузок. И все же конкретная рабочая нагрузка должна замеряться отдельно — синтетика не заменяет тестирование на копии продакшен-базы.

Long-running транзакции и vacuum

С TPS связан и vacuum. Долгие читающие транзакции в опенсорсе блокируют autovacuum от очистки старых версий строк. Допустим, аналитический отчет выполняется час — за это время бэкап MVCC-цепочки разрастается, и latency на OLTP-запросах ухудшается. У западного аналога подобной проблемы нет: long-running транзакции мешают только своими блокировками. Решение в открытой системе очевидное — выносить OLAP-нагрузку на read-реплику или использовать pg_repack для онлайн-перестройки таблиц.

Поведение под пиковой записью

Самый тяжелый сценарий — пиковая запись. При записи в одну таблицу на 5000+ TPS открытое решение упирается в WAL-flush и контеншн на блокировках buffer pool. Платформа Редмонда тут масштабируется агрессивнее за счет in-memory OLTP (Hekaton) и accelerated database recovery. Если профиль рабочей нагрузки — биллинг, телематика, торговый поток — разрыв в производительности заметен. А вот у типового ERP или CRM разница нивелируется правильным шардингом или партиционированием на отечественной сборке.

Аналитика и сложные запросы — TPC-H, параллелизм, OLAP

С OLTP все понятно — переходим к аналитике. Именно она раскрывает работу планировщика и подсистем параллельного выполнения.

Параллелизм и планировщик

В свободном движке параллелизм работает с версии 9.6 и активно развивается: parallel sequential scan, parallel hash join, parallel aggregate. Правда, по умолчанию max_parallel_workers_per_gather равен 2 — этого мало. Подняв до 4–8 на тяжелых запросах, получаем линейный рост на отчетах. У платформы из Редмонда параллелизм исторически зрелее: оптимизатор сам решает, дробить ли запрос, и есть batch mode для columnstore. В цифрах это выглядит так: на TPC-H-подобных бенчмарках разница между двумя продуктами на одном железе обычно укладывается в 15–30% в пользу решения Microsoft на ядре. Но открытый движок отыгрывает за счет расширений вроде Citus или TimescaleDB при правильной архитектуре.

Колоночное хранение и OLAP-расширения

Колоночное хранение — отдельная история. В коммерческом продукте есть нативный columnstore с batch mode, и для аналитики на десятках миллионов строк это сильное преимущество. Открытый аналог решает ту же задачу через cstore_fdw, Hydra, ParadeDB или сторонние OLAP-движки — рядом всегда есть ClickHouse. И все же если бизнесу нужен полноценный DWH — рассматривайте отдельный аналитический контур, а не пытайтесь делать витрину на OLTP-базе любой из двух баз.

JSON и полуструктурированные данные

А вот тут открытое решение играет на своей территории. JSON в опенсорсе с типом jsonb — индексируемая бинарная структура с GIN-индексами. По производительности она на 30–50% быстрее, чем JSON в западном продукте, на типичных запросах с фильтрацией по ключам. Поэтому если у вас в логике приложения активно используется JSON — это аргумент в пользу открытой системы даже без учета лицензий.

Репликация и отказоустойчивость

Производительность кластера зависит не только от движка, но и от того, как настроена репликация и как обрабатывается отказ узла.

Физическая и логическая репликация

Здесь у обеих систем зрелые решения. В открытом движке потоковая физическая репликация (streaming replication) встроена с версии 9.0, работает быстро, лагает минимально. Логическая репликация (logical replication) появилась с версии 10 и позволяет реплицировать отдельные таблицы между разными версиями. Hot standby при этом читает реплику в режиме только для чтения. В западном продукте свой набор — Always On Availability Groups, AlwaysOn FCI и log shipping, каждый со своими нюансами. На практике обе системы дают сравнимую надежность при грамотной настройке.

HA-кластеры и автопереключение

Дальше — автоматическое переключение при отказе. Для failover в опенсорсе используется связка Patroni + etcd/Consul + HAProxy. В коммерческом аналоге — встроенный Always On с Windows Server Failover Clustering (WSFC). И вот где видна экономия: стоимость инфраструктуры под кластер на опенсорсе примерно в 1.5–2 раза ниже за счет отсутствия лицензий Windows Server и Datacenter Edition. По надежности при правильной конфигурации обе платформы дают RPO около нуля и RTO 10–30 секунд.

Резервное копирование

Аналогичная картина с бэкапами. В открытом мире выбор богатый — pg_basebackup, pgBackRest, Barman, WAL-G. Все они зрелые, поддерживают инкрементальное копирование, PITR (point-in-time recovery), сжатие, шифрование, выгрузку в S3. В западной экосистеме — встроенный backup engine с разными уровнями (full, differential, transaction log). На большой базе (10+ ТБ) pgBackRest с дельта-копированием часто работает заметно отзывчивее встроенных средств западной экосистемы.

PostgreSQL для 1С — реальная картина

Это тема, по которой больше всего мифов. Поэтому разберем по фактам.

Apdex и реальные цифры внедрений

Начнем с замеров. По данным методики Gilev.ru, на типовой конфигурации УТ 11 с 50 активными пользователями коэффициент Apdex на корректно настроенном Postgres Pro Enterprise 1С-сборки находится в диапазоне 0.85–0.95 (отлично) — тот же уровень, что и на хорошо настроенной MS-платформе. На 100+ пользователях разрыв до 5–10% в пользу западной платформы при «голой» конфигурации. После оптимизации — паритет.

Что критично для рабочей нагрузки 1С

Чтобы получить эти цифры, важно сразу заложить ряд вещей. На быстродействие 1С на отечественной сборке влияет: версия (Enterprise лучше Standard за счет CFS-компрессии и AQO-автоподстройки планов), правильные параметры (shared_buffers, work_mem, effective_cache_size), отключение JIT для ряда запросов, регламентные операции (vacuum analyze, переиндексация) и грамотный сервер. Конфигуратор серверов от Serverzilla помогает подобрать платформу под прогнозируемое число пользователей и объем базы.

Подводные камни

Теперь о ловушках. Сравнение запросов покажет: 1С генерирует SQL, нацеленный на западный продукт, поэтому ряд запросов в опенсорсе работает медленнее без патчей Postgres Professional. Отсюда правило: ставьте 1С-сборку, а не ванильную дистрибуцию — это принципиально. Дальше — регулярно следите за autovacuum, иначе со временем будет деградация. И последнее — используйте СХД с low-latency NVMe, потому что 1С чувствительна к IOPS, а не к sequential.

Стоимость владения, лицензии и миграция

Структура TCO

Перейдем к деньгам. Считаем по двум сценариям на 5 лет для базы среднего размера (8 ядер, 64 ГБ RAM, 2 ТБ NVMe):

Сравнение стоимости владения: Microsoft SQL Server vs Postgres Pro
Параметр	Microsoft SQL Server Standard	Postgres Pro Enterprise
Лицензии СУБД	~3.8 млн руб (8 core packs)	~700 тыс руб (8 ядер на 5 лет)
Лицензии ОС	Windows Server Datacenter	Astra Linux SE / РЕД ОС
Поддержка вендора	ограничена в РФ	штатная, на русском
Миграция и обучение	—	~300–600 тыс единоразово
Итого за 5 лет	5–6 млн руб	1.2–1.8 млн руб

Скрытые затраты на переход

Цифры впечатляют, но за рамками лицензий есть и другие траты. В бюджет переноса закладываем: аудит схемы и стороннего SQL-кода, переписывание хранимых процедур (синтаксис T-SQL отличается от PL/pgSQL), смену ETL/BI-коннекторов, перенастройку мониторинга, тестирование, перенос данных через pg_dump/pg_restore или pgloader и обучение администраторов. Чем больше зрелого T-SQL у команды — тем дороже переход. Универсальный совет: начинайте с пилота на одной системе, прежде чем переносить ландшафт целиком.

Когда переход не оправдан

Технический паритет — еще не повод бежать. Откажитесь от переноса, если у вас остались годные лицензии Software Assurance и нет требований КИИ. Также — если в проекте критична функциональность SSAS, SSIS, SSRS, MDS, Master Data Services без готовых аналогов в опенсорсе. И — если команда полностью на T-SQL и нет ресурсов для повышения квалификации.

Чек-лист по выбору серверной базы

Сведем выводы в чек-лист — что и где выбирать.

Выбирайте свободное решение и отечественную сборку, если:

объект попадает под требования КИИ или 187-ФЗ, нужен российский софт из реестра Минпромторга;
ландшафт построен на 1С (УТ, БП, ЗУП, ERP) с числом пользователей до 200;
в приложении активно работают json-документы, геоданные, time-series;
бюджет ограничен, важна предсказуемая TCO;
команда готова инвестировать в обучение администраторов.

Оставайтесь на западном продукте, если:

есть действующие лицензии Software Assurance, нет регуляторных рисков;
основной стек — SSAS/SSIS/SSRS/Power BI с глубокой интеграцией;
крупный аналитический контур работает на columnstore с batch mode;
команда годами заточена под T-SQL, времени на переход нет.

Краткое сравнение — таблица

Сравнение PostgreSQL и Microsoft SQL Server
Критерий	Свободная СУБД (PostgreSQL/Postgres Pro)	Microsoft SQL Server
Лицензии	Open-source / отечественная коммерческая	Проприетарная, не продается в РФ
Реестр Минпромторга	Да (Postgres Pro)	Нет
OLTP, TPS на 16 ядрах	После настройки — ~85–95% от конкурента	Эталон в сегменте
OLAP/аналитика	Через расширения (Citus, cstore_fdw)	Нативный columnstore + batch mode
JSON	jsonb с GIN-индексами, быстрее	JSON-функции, медленнее
Репликация	Streaming + logical, Patroni	Always On, WSFC
Поддержка 1С	Сертифицирована, нужны 1С-сборки	Эталон в сегменте
Стоимость владения	В 3–5 раз ниже	Высокая, осложнена санкциями

FAQ

Можно ли мигрировать с MS-сервера на свободную СУБД без потери производительности?

При грамотном тюнинге быстродействие сопоставимо для большинства сценариев. На чистом OLTP в пиковой записи разрыв сохраняется в 5–15%, на аналитике с расширениями — паритет или преимущество. Главное — заложить в проект бюджет на тонкую настройку и обучение.

Что выбрать: ванильный PostgreSQL или Postgres Pro?

Для коммерческой эксплуатации в продакшене с 1С, ECM, ERP — российскую сборку Postgres Pro. В ней есть критичные патчи под 1С, CFS-компрессия (сжатие данных), AQO (автоподстройка планов запросов), русскоязычная поддержка от Postgres Professional. Ванильный движок подходит для разработки, обучения, некритичных сред.

Что с производительностью JSON-операций?

В открытой базе тип jsonb — индексируемый, GIN-индекс ускоряет поиск по ключам и значениям внутри JSON в десятки раз. В западном аналоге JSON хранится как текст, индексировать сложнее. Если бизнес-логика построена на JSON-документах — это весомый аргумент за опенсорс.

Сколько стоит миграция средней базы?

Перенос базы 500 ГБ — 2 ТБ с типовой ERP-нагрузкой: 3–6 месяцев календарного времени, бюджет 1.5–4 млн рублей на работу команды (аудит, перенос, тестирование, обучение). Окупаемость за счет лицензионных платежей — 6–18 месяцев.

Как замерить производительность до миграции?

Снимите профиль рабочей нагрузки на боевой базе (sp_BlitzFirst, Query Store), выделите топ-50 тяжелых запросов, перенесите тестовый контур, прогоните те же запросы на свободной СУБД. Метрики: latency p95, p99, TPS, использование CPU и IO. Так увидите реальные узкие места до того, как пойдет продуктив.

Итоги

Сравнение двух баз в 2026 году — это уже не «что технически круче», а «что разрешено и что разумно». Открытый движок с отечественной сборкой Postgres Pro закрывает 90–95% сценариев на уровне западного аналога, а при правильной архитектуре — без компромиссов по быстродействию. MS-стек остается эталоном в нишах с тяжелой нативной OLAP-аналитикой и зрелым стеком SSIS/SSAS. Для большинства российских компаний переход на свободное решение оправдан экономически, технически и регуляторно. Решающий фактор — готовность команды и инвестиции в тонкую настройку.

Чтобы развернуть отказоустойчивый кластер с автоматическим переключением на отечественной базе с прогнозируемой нагрузкой, рассмотрите серверы Serverzilla на базе AMD EPYC и готовые решения для баз 1С. Команда поможет рассчитать конфигурацию под профиль рабочей нагрузки и обеспечить миграцию без простоев.