PostgreSQL напоминает швейцарский нож с расширениями, а Microsoft SQL Server — профессиональный инструмент с готовым обвесом. Оба режут, оба считают, но логика выбора изменилась радикально. MS SQL Server официально не продается российским заказчикам с 2022 года, органам власти и заказчикам по 223-ФЗ запрещено использовать иностранное ПО на своих значимых объектах КИИ, а Postgres Pro дозрел до уровня, на котором внедрения 1С:ERP на 100+ пользователей перестали быть подвигом.
Дальше разберем по порядку: где PostgreSQL медленнее MS SQL Server, где быстрее, как меняется стоимость владения после миграции и какие подводные камни ждут команду. И главное — с реальными цифрами по TPC-C, бенчмарками pgbench и опытом на 1С через метрику Apdex (Application Performance Index — индекс удовлетворенности пользователя от 0 до 1, где 1 значит, что все запросы отрабатывают мгновенно) от сервиса Gilev.ru.
Почему вокруг этого сравнения столько шума в 2026
Сначала о терминах: SQL — язык запросов, а Microsoft SQL Server и PostgreSQL — системы управления базами данных, которые его используют. Поэтому вопрос «SQL или PostgreSQL» на деле означает выбор между двумя СУБД с разной архитектурой, лицензированием и доступностью в России.
Большинство российских заказчиков либо уже мигрировало, либо находится в процессе планирования. И вот почему.
Импортозамещение и реестр Минпромторга
Начнем с регуляторики. С 1 января 2025 года органам государственной власти и заказчикам по 223-ФЗ запрещено использовать иностранное ПО на принадлежащих им значимых объектах КИИ (Указ Президента № 166). Приказ ФСТЭК № 117 к этому запрету не относится: он задает требования к защите информации в ГИС и иных информационных системах госорганов и госучреждений и действует с 1 марта 2026 года. Microsoft SQL Server в единый реестр российских программ для ЭВМ и баз данных (его ведет Минцифры) отсутствует, а Postgres Pro Standard и Enterprise зарегистрированы в нем отдельными записями. Поэтому для таких организаций выбор СУБД — не вопрос предпочтений, а требование закона.
Уход западной СУБД с прайс-листов российских интеграторов
Регуляторика — не единственный драйвер. Microsoft прекратила продажи в России в 2022 году: действующие лицензии работают, новые официально не выдаются. Software Assurance не продлевается, доступ к серверным обновлениям ограничен. Поддержку продлевают через зарубежные аккаунты, а это уже серая зона по лицензионной чистоте. В итоге большинство интеграторов убрали MS SQL Server из коммерческих предложений и пересобрали стек на PostgreSQL и Postgres Pro.
Готовность 1С, бухгалтерских и ERP-систем к Postgres Pro
Третий драйвер — экосистема. С 2022 года фирма «1С» включила отечественный дистрибутив в список официально рекомендуемых баз. Специальные сборки 1С-варианта Postgres Pro дают сопоставимую с конкурентом рабочую нагрузку на типовых конфигурациях УТ 11, БП, ЗУП, ERP. Аналогично прошли сертификацию модули БИТ.Финанс, ELMA365, 1С-Битрикс и многие ECM-системы. То есть прикладной слой к переезду давно готов.
Архитектурные различия
Под капотом PostgreSQL и MS SQL Server устроены по-разному, и понимание этих различий помогает заранее увидеть, где будет узкое место после переноса.
MVCC против блокировок на уровне строк
Открытый движок использует MVCC (Multi-Version Concurrency Control): каждая транзакция видит свою версию данных, читатели не блокируют писателей и наоборот. Цена за это удобство — фоновая работа vacuum, который удаляет устаревшие версии строк. У платформы Редмонда подход иной: по умолчанию работают блокировки на уровне строк (row-level locking) с механизмом READ COMMITTED через блокировки. Уровень isolation snapshot включается отдельно и приближает поведение к MVCC. На практике это выливается в следующее: открытое решение чище ведет себя на длинных читающих транзакциях, а коммерческий аналог — на коротких OLTP с пиковой записью.
Один процесс на соединение против пула потоков
Дальше — модель соединений. Свободный движок создает отдельный процесс ОС на каждое подключение. С одной стороны, это дает изоляцию — упавший процесс не роняет сервер. С другой — требует памяти, потому что каждый процесс ест 5–15 МБ только под структуру. Для сотен подключений нужен pgBouncer или встроенный pool на стороне приложения. Коммерческий конкурент идет другим путем — использует thread pool внутри одного процесса, поэтому соединения у него дешевле. Но под нагрузку 500+ конкурентных коннектов без пулера лучше не выходить ни в одном случае. Практический вариант настройки пула рассматривает PostgreSQL для 500+ подключений и pgBouncer.
Расширения против встроенных модулей
Третье отличие — модель функциональности. Открытая система — это ядро плюс экосистема расширений: 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) на сопоставимом железе обычно показывают преимущество Microsoft SQL Server над PostgreSQL «из коробки» за счет более агрессивного планировщика и thread pool под высокую конкурентность. После настройки PostgreSQL (shared_buffers около 25% RAM, work_mem 16–64 МБ, max_parallel_workers по числу ядер, autovacuum_max_workers) разрыв на большинстве реальных нагрузок заметно сокращается. Результаты таких тестов сильно зависят от размера базы, числа виртуальных пользователей и настроек обеих СУБД, поэтому чужие проценты на свой проект не переносят: конкретную нагрузку замеряют отдельно, на копии продакшен-базы.
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 и полуструктурированные данные
А вот тут открытое решение играет на своей территории. В PostgreSQL тип jsonb — индексируемая бинарная структура с GIN-индексами, а в Microsoft SQL Server JSON исторически хранится как текст и индексируется через вычисляемые столбцы. На запросах с фильтрацией по ключам это обычно дает PostgreSQL преимущество, величину которого проверяют на своих данных. Поэтому если у вас в логике приложения активно используется 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С — реальная картина
Для 1С берут не ванильный PostgreSQL, а 1С-сборку Postgres Pro: 1С генерирует SQL в расчете на MS SQL Server, и без патчей Postgres Professional часть запросов работает медленнее. Postgres Pro входит в список СУБД, которые поддерживает платформа «1С:Предприятие», и на типовых конфигурациях УТ 11, БП и ЗУП при корректной настройке он дает сопоставимую производительность. Для этого сразу закладывают параметры shared_buffers, work_mem и effective_cache_size, регламентные vacuum analyze и переиндексацию, а под базу ставят NVMe с низкой задержкой, потому что 1С чувствительна к IOPS.
Главные отличия проявляются на блокировках и тяжелых сценариях. Модель MVCC в PostgreSQL не дает читателям блокировать писателей, но требует следить за autovacuum, иначе база со временем деградирует. На больших базах со 100 и более активными пользователями MS SQL Server без дополнительной оптимизации пока работает быстрее, и этот разрыв закрывают настройкой запросов и индексов, которую разбирает статья оптимизация PostgreSQL и SQL Server под 1С. Конфигуратор серверов от Serverzilla помогает подобрать платформу под прогнозируемое число пользователей и объем базы.
Стоимость владения, лицензии и миграция
Структура TCO
Перейдем к деньгам.
Сравним статьи затрат для базы среднего размера (8 ядер, 64 ГБ RAM, 2 ТБ NVMe). Цены Microsoft указаны рекомендованные, в долларах США: официальных продаж в России нет, и рублевые цены на рынке иные.
| Параметр | Microsoft SQL Server Standard | Postgres Pro Enterprise |
|---|---|---|
| Лицензии СУБД | 4 пакета по 2 ядра × $3 945 = $15 780 | Лицензия на ядро плюс поддержка, цена по запросу у Postgres Professional |
| Лицензии ОС | Windows Server Standard на 16 ядер, $1 176 | Astra Linux SE / РЕД ОС |
| Поддержка вендора | Ограничена в РФ | Штатная, на русском |
| Миграция и обучение | Не требуется | Оценивают по итогам аудита схемы и пилотного переноса |
ОС лицензируется минимум на 16 ядер даже для 8-ядерного сервера, правила подсчета разбирает статья лицензирование Windows Server по ядрам.
Скрытые затраты на переход
Помимо лицензий, в бюджет перехода входят и другие траты. В бюджет переноса закладываем: аудит схемы и стороннего 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 и нет ресурсов для повышения квалификации.
Чек-лист по выбору серверной базы
Сведем выводы в чек-лист — что и где выбирать.
Выбирайте свободное решение и отечественную сборку, если:
- организация — орган власти или заказчик по 223-ФЗ со значимыми объектами КИИ, где нужно ПО из единого реестра российских программ;
- ландшафт построен на 1С (УТ, БП, ЗУП, ERP) с числом пользователей до 200;
- в приложении активно работают json-документы, геоданные, time-series;
- бюджет ограничен, важна предсказуемая TCO;
- команда готова инвестировать в обучение администраторов.
Оставайтесь на западном продукте, если:
- есть действующие лицензии Software Assurance, нет регуляторных рисков;
- основной стек — SSAS/SSIS/SSRS/Power BI с глубокой интеграцией;
- крупный аналитический контур работает на columnstore с batch mode;
- команда годами заточена под T-SQL, времени на переход нет.
Краткое сравнение — таблица
| Критерий | PostgreSQL / Postgres Pro | Microsoft SQL Server |
|---|---|---|
| Лицензии | Open-source / отечественная коммерческая | Проприетарная, не продается в РФ |
| Реестр российского ПО (Минцифры) | Да (Postgres Pro) | Нет |
| OLTP, TPS на 16 ядрах | После настройки близко к MS SQL Server, разрыв зависит от нагрузки | Эталон в сегменте |
| OLAP/аналитика | Через расширения (Citus, cstore_fdw) | Нативный columnstore + batch mode |
| JSON | jsonb с GIN-индексами, быстрее | JSON-функции, медленнее |
| Репликация | Streaming + logical, Patroni | Always On, WSFC |
| Поддержка 1С | Сертифицирована, нужны 1С-сборки | Эталон в сегменте |
| Стоимость владения | Ниже за счет лицензий, но есть затраты на миграцию | Высокая, осложнена санкциями |
FAQ
Можно ли мигрировать с MS-сервера на свободную СУБД без потери производительности?
При грамотном тюнинге быстродействие сопоставимо для большинства сценариев. На чистом OLTP в пиковой записи разрыв сохраняется, на аналитике с расширениями возможен паритет или преимущество. Величину разрыва для своего проекта замеряют на копии продакшен-базы. Главное — заложить в проект бюджет на тонкую настройку и обучение.
Что выбрать: ванильный PostgreSQL или Postgres Pro?
Для коммерческой эксплуатации в продакшене с 1С, ECM, ERP — российскую сборку Postgres Pro. В ней есть критичные патчи под 1С, CFS-компрессия (сжатие данных), AQO (автоподстройка планов запросов), русскоязычная поддержка от Postgres Professional. Ванильный движок подходит для разработки, обучения, некритичных сред.
Что с производительностью JSON-операций?
В открытой базе тип jsonb — индексируемый, GIN-индекс ускоряет поиск по ключам и значениям внутри JSON в десятки раз. В западном аналоге JSON хранится как текст, индексировать сложнее. Если бизнес-логика построена на JSON-документах — это весомый аргумент за опенсорс.
Сколько стоит миграция средней базы?
Сроки и бюджет зависят от объема хранимых процедур T-SQL, числа интеграций и требований к тестированию, поэтому их оценивают по итогам аудита схемы и пилотного переноса одной системы. Окупаемость считают по разнице лицензионных платежей за срок эксплуатации.
Как замерить производительность до миграции?
Снимите профиль рабочей нагрузки на боевой базе (sp_BlitzFirst, Query Store), выделите топ-50 тяжелых запросов, перенесите тестовый контур, прогоните те же запросы на свободной СУБД. Метрики: latency p95, p99, TPS, использование CPU и IO. Так увидите реальные узкие места до того, как пойдет продуктив.
Итоги
Сравнение PostgreSQL и MS SQL Server — это уже не «что технически круче», а «что разрешено и что разумно». PostgreSQL и Postgres Pro закрывают большинство сценариев на уровне MS SQL Server, а при правильной архитектуре — без компромиссов по быстродействию. MS SQL Server остается эталоном в нишах с тяжелой нативной OLAP-аналитикой и зрелым стеком SSIS/SSAS. Для большинства российских компаний переход на свободное решение оправдан экономически, технически и регуляторно. Решающий фактор — готовность команды и инвестиции в тонкую настройку.
Чтобы развернуть отказоустойчивый кластер с автоматическим переключением на отечественной базе с прогнозируемой нагрузкой, рассмотрите серверы Serverzilla на базе AMD EPYC и готовые решения для баз 1С. Команда поможет рассчитать конфигурацию под профиль рабочей нагрузки и обеспечить миграцию без простоев.