Переезжать ли с MS SQL на PostgreSQL? Честно от того, кто PostgreSQL не любит

Коллеги, привет!

Тема, вокруг которой у меня накопилось больше всего личного. Пишу с прицелом на то, что читать будут админы и руководители, которые сейчас сидят на MS SQL и слышат со всех сторон "пора переезжать на постгрес".

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

Сразу обозначу позицию

Чтобы дальше читалось честно.

Я не фанат PostgreSQL. Мне MS SQL нравится больше, и я не собираюсь это прятать за нейтральными формулировками.

Причина простая и приземленная: администрировать MS SQL на Windows удобнее. Открыл студию, увидел базы, планы обслуживания, задания агента, ожидания, статистику - все в одном окне, все мышкой, все понятно. Бэкап настраивается за десять минут визардом, и он просто работает.

В PostgreSQL половина этого делается руками, вторая половина - через утилиты командной строки, а планировщика заданий внутри вообще нет. Это не катастрофа, но это другой уровень удобства, и человек, привыкший к студии, первое время чувствует себя так, будто у него забрали инструменты и выдали напильник.

Так вот. Все, что дальше - это не агитация за переезд. Это разбор, при каких условиях он оправдан, при каких нет, и как не убить производительность, если решились.

Почему вопрос все равно встал

Если бы дело было только в моих симпатиях, статьи бы не было. Но есть несколько вещей, которые от симпатий не зависят.

Первое. Лицензии. Купить новые лицензии MS SQL в России легально сейчас нельзя. Не "сложно", не "дорого" - именно нельзя нормальным путем. То, что вы видите на маркетплейсах по подозрительной цене, лучше не рассматривать вообще: это риск, который в один прекрасный день превращается в проблему.

Значит, старые лицензии есть - работайте. Растете, нужны новые - а вот тут начинается вопрос.

Второе. Поддержка версий заканчивается. И это не абстракция, это календарь:

Обратите внимание на первую строку. SQL Server 2016 официально мертв с июля этого года. Обновлений безопасности больше нет. А сидит на нем до сих пор огромное количество компаний, потому что "работает же".

Работает. До первой дырки, которую никто не закроет.

Третье. Express и его потолок. Много кто живет на бесплатной редакции MS SQL Express. Она бесплатная, но у нее жесткий лимит на размер базы - 10 гигабайт. И база растет. И в какой-то день упирается.

Дальше развилка: покупать Standard (нельзя) или переезжать. У PostgreSQL такого лимита нет вообще - и вот это, пожалуй, самый честный аргумент за переезд из всех, что я знаю.

Про сроки импортозамещения: паника отменяется

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

Да, есть Указ Президента № 166 и требования по переходу значимых объектов КИИ на отечественное ПО. Да, СУБД в этот периметр входит.

Но в мае этого года сроки сдвинули, и сдвинули сильно:

• базовый срок - 1 января 2028 года для значимых объектов КИИ;
• до 1 января 2031 года - если реализован особо значимый проект или заключен контракт на разработку отечественного ПО;
• до 1 января 2036 года - для организаций, привлеченных к особо значимым проектам в 2026-2027 годах.

И ключевое, о чем почти не говорят продавцы миграций: штрафов за неисполнение в законодательстве не предусмотрено.

Что из этого следует практически.

Если вы обычная коммерческая компания - торговля, услуги, производство без критической инфраструктуры - вас требования по КИИ не касаются вообще. Переезжайте по технической необходимости, а не потому что "все переезжают".

Если вы госсектор, госкомпания или значимый объект КИИ - да, планировать надо. Но у вас есть годы, а не месяцы. Спокойно, поэтапно, с тестами. Не в авральном режиме за квартал до отчета.

Кому переезжать НЕ надо

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

Не надо, если у вас файловая база. Там вообще нет никакой СУБД, вопрос не про вас. Ваша развилка - переходить ли на клиент-серверный вариант в принципе, а это отдельный разговор.

Не надо, если у вас работающий MS SQL с действующей лицензией и версия еще поддерживается. Работает - пусть работает. Переезд ради переезда - это оплаченный риск без выгоды.

Не надо, если база плотно завязана на COM-компоненты и внешние обработки под Windows. Если вместе с СУБД вы переезжаете и на Linux - половина этого хозяйства просто отвалится. Печатные формы через ворд, обмены через COM, специфические внешние компоненты - все это придется переделывать, и это отдельный бюджет.

Не надо прямо сейчас, если у вас база больше 500 гигабайт и сложная аналитика. MS SQL на таких объемах и сложных запросах пока объективно сильнее за счет оптимизатора. Переехать можно, но готовьтесь к серьезной работе по оптимизации запросов, а не к "перенесли и забыли".

И не надо, если у вас в штате нет никого, кто хотя бы читал про PostgreSQL. Экономия на лицензиях, съеденная зарплатой человека, который умеет это администрировать, - классика жанра. Считайте не стоимость лицензии, а стоимость владения целиком.

Кому переезжать надо

Теперь честно в другую сторону.

Уперлись в 10 гигабайт на Express. Тут даже думать не о чем. Это самый частый и самый бесспорный случай.

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

Госсектор, госкомпании, значимые объекты КИИ. Не завтра, но планировать надо начинать.

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

Уже переезжаете на Linux по другим причинам. Тогда PostgreSQL - естественный выбор, MS SQL под Linux с 1С это экзотика.

Главный миф: "постгрес тормозит на винде"

Вот тут я хочу разобраться внимательно, потому что сам эту фразу произносил, и она требует уточнения.

Техническая основа у нее есть. В Linux новые процессы создаются системным вызовом fork - быстро и с разделяемой памятью. В Windows такого механизма нет, и PostgreSQL его эмулирует. Эмуляция стоит ресурсов. Отсюда и родилось "на винде постгрес хуже".

А теперь неудобная правда: когда это проверяют замерами, катастрофической разницы не находят. В тестах, которые я смотрел, среднее время отклика на Windows и Linux расходится в пределах пары процентов - это статистический шум, а не деградация.

Так почему у людей реально тормозит?

Потому что путают две разные вещи. Тормозит не Windows. Тормозит ванильная сборка с настройками по умолчанию. А ставят ее обычно как раз на Windows, потому что там это делается в три клика мастером установки, и человек искренне считает, что на этом настройка закончена.

На Linux же обычно ставят по инструкции, где сразу прописаны параметры под 1С. Отсюда и ощущение, что "на линуксе быстрее".

Мой практический вывод: на Windows PostgreSQL жить может. Не идеально, но может. При двух условиях: правильная сборка и настроенный конфиг. Если хотите выжать максимум и вас не пугает командная строка - Linux, конечно, предпочтительнее, там и накладных расходов меньше, и лицензия на саму ОС не нужна.

Но "мы не пойдем на постгрес, потому что у нас винда" - аргумент несостоятельный. 1С официально поддерживает PostgreSQL на Windows Server вплоть до 2025-й версии.

Ошибка номер один: ванильная сборка

Если из всей статьи вы запомните один абзац - пусть это будет этот.

Обычный PostgreSQL, скачанный с официального сайта, для 1С не годится. Он запустится, база подключится, все будет выглядеть работающим. И будет тормозить так, что вы проклянете тот день.

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

Первый: PostgreSQL с патчами от фирмы 1С. Актуальные сборки на сегодня - 18.4-1.1С, 17.10-2.1С, 16.14-1.1С, 15.18-1.1С, 14.23-1.1С. Скачивается с портала релизов при действующем ИТС. Фактически бесплатно - вы за это уже платите подпиской.

Второй: Postgres Pro. Коммерческая российская сборка, есть редакции 1C, Standard, Enterprise и сертифицированная. В реестре отечественного ПО под номером 104. Заявляют прирост до 30 процентов, есть сертифицированная ФСТЭК версия, встроенный кластер отказоустойчивости, менеджер управления и своя система бэкапов.

Что выбрать. Малому и среднему бизнесу - сборку от 1С. Она бесплатная, поддерживается официально, и для типовых нагрузок ее достаточно. Госсектору и тем, кому нужна сертификация ФСТЭК или отечественная СУБД в реестре, - Postgres Pro, тут просто нет альтернативы.

А вот ванильный PostgreSQL с postgresql.org - не ставьте. Ни на винду, ни на линукс.

Случай, который повторяется с пугающей регулярностью.

Приходит запрос: "переехали на постгрес, стало хуже, чем было на MS SQL, помогите вернуть обратно". Начинаешь смотреть - стоит обычный PostgreSQL с официального сайта, поставленный мастером в три клика. Конфиг не тронут вообще: shared_buffers на дефолте, автоочистка на дефолте, патчей от 1С нет.

Дальше все скучно. Ставим правильную сборку, переносим базу, прописываем параметры под нагрузку. Проведение документов ускоряется в разы, и человек искренне удивляется: он-то был уверен, что "постгрес просто не тянет 1С".

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

Где PostgreSQL реально хуже, и это не лечится

Раз обещал честно - вот вещи, которые мне в PostgreSQL не нравятся и которые настройками не чинятся.

Временные таблицы. Это главное. В MS SQL под них есть отдельная база tempdb, оптимизированная именно под эту работу. В PostgreSQL временные таблицы живут в той же базе и метаданными ничем не отличаются от постоянных.

А 1С временные таблицы использует ОЧЕНЬ активно - в сложных запросах их создаются и удаляются десятки за одно проведение документа. Каждая такая операция дергает системный каталог. При интенсивной работе системные таблицы распухают, и производительность начинает проседать - причем не сразу, а через недели работы.

Лечится это грамотной настройкой автоочистки, но лечится именно как симптом. Архитектурно tempdb удобнее, и с этим ничего не сделать.

Планировщик запросов. PostgreSQL чаще ошибается с планом на сложных соединениях. Классика: выбирает Nested Loop там, где нужен Hash Join, и запрос вместо секунды выполняется восемь.

Свежий пример из практики сообщества: запрос 1С выполнялся 7300 миллисекунд, после правильной оптимизации соединения - 365 миллисекунд. Разница в двадцать раз. И это не редкость.

В MS SQL таких сюрпризов меньше, а если они случаются - есть подсказки оптимизатору. В PostgreSQL инструментов влияния на план меньше.

Нет своего планировщика заданий. В MS SQL есть SQL Server Agent - расписания, задания, оповещения об ошибках, все внутри. В PostgreSQL этого нет вообще, регламентные операции запускаются планировщиком операционной системы. Работает, но это уже не "все в одном окне".

Инструменты управления слабее. Скажу как есть: pgAdmin - это не SQL Server Management Studio. Он неплох, но студия удобнее, и я не буду делать вид, что это не так.

Администрирование: чем заменить SSMS

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

pgAdmin 4 - штатная веб-консоль. Умеет все базовое: базы, таблицы, запросы, права, мониторинг активности. Бесплатно, идет в комплекте. Первую неделю будет раздражать, потом привыкаете))

DBeaver - универсальный клиент, многим нравится больше pgAdmin. Работает и с MS SQL тоже, что удобно на время переходного периода: одно окно, обе базы, наглядное сравнение.

Postgres Pro Enterprise Manager - если взяли Postgres Pro Enterprise, там есть своя графическая платформа управления и мониторинга. Вот это уже ближе по духу к тому, к чему привык админ MS SQL.

Расширения для диагностики - ставятся отдельно и, на мой взгляд, обязательны:

• pg_stat_statements - статистика по запросам: какой сколько раз выполнялся и сколько времени съел. Аналог Query Store. Без него вы слепой;
• auto_explain - автоматически пишет в лог план выполнения для медленных запросов. Незаменимая штука, когда тормоза плавающие и поймать их руками не получается;
• online_analyze - обновляет статистику по временным таблицам сразу после заполнения. Для 1С практически обязателен, иначе планировщик работает вслепую именно там, где это критично.

Бэкапы: чем заменить планы обслуживания

Самый болезненный пункт для человека, привыкшего к MS SQL. Разбираю по инструментам.

pg_dump - логическая выгрузка. Аналог не бэкапа, а скорее выгрузки в .dt: удобно перенести базу, но для регулярного резервного копирования большой базы медленно.

pg_basebackup - штатная бинарная копия всего кластера. Быстрее, ближе к полному бэкапу в понимании MS SQL. Входит в комплект.

pg_probackup - вот это главный инструмент, и его я советую ставить сразу. Разработка Postgres Professional, бесплатная. Умеет:

• инкрементальные копии - аналог differential backup;
• восстановление на момент времени (PITR) - то же, что point-in-time restore, только через архив WAL;
• проверку целостности копии без восстановления - вот это прямо ценно, в MS SQL для этого надо разворачивать;
• восстановление отдельной базы из копии кластера;
• проверку контрольных сумм.

WAL - журнал предзаписи, идейный аналог журнала транзакций MS SQL. Именно его архивирование дает возможность восстановиться на любой момент, а не только на время последнего полного бэкапа. Настраивать архивирование WAL - обязательно, без него PITR не существует.

Расписание. Планировщика внутри нет, поэтому: на Linux - cron, на Windows - Планировщик заданий. Скрипт, расписание, и обязательно уведомление об ошибке. В MS SQL агент сам напишет письмо, тут придется дописать руками.

И общее правило, которое от СУБД не зависит: копию надо периодически разворачивать и проверять. Про это я писал отдельно, повторяться не буду, но актуальность после переезда только вырастает - схема-то новая, необкатанная.

Обслуживание: autovacuum вместо реиндексации

Тут смена мышления, и на ней спотыкаются почти все.

В MS SQL вы привыкли к планам обслуживания: перестроение индексов, обновление статистики, проверка целостности - по расписанию, ночью, мышкой настроено.

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

Ключевое слово - "сам". И вот тут ловушка: настройки по умолчанию рассчитаны на абстрактную нагрузку, а не на 1С. Если их не тронуть, автоочистка на активной базе просто не успевает, база пухнет, запросы замедляются.

Что надо сделать осознанно:

• настроить агрессивность autovacuum под вашу нагрузку - чаще и мельче, а не редко и большими кусками;
• отдельно настроить очистку системного каталога - помните про временные таблицы, именно там копится мусор;
• проверить память: shared_buffers, work_mem, temp_buffers, max_wal_size. Дефолтные значения смешные и рассчитаны на то, чтобы запуститься на любом утюге;
• следить за раздуванием таблиц - есть готовые запросы, которые показывают, сколько в таблице мусора;
• REINDEX по необходимости - не по расписанию каждую ночь, как в MS SQL, а когда действительно нужно.

Если оставить конфиг по умолчанию - вы получите ровно те тормоза, из-за которых потом скажете "постгрес не тянет". Не постгрес не тянет. Конфиг не тронут)

Таблица соответствий для админа MS SQL

Собрал шпаргалку: что чем заменяется. Распечатайте, пригодится в первый месяц))

Сколько это стоит на самом деле

По-честному, с учетом всего.

Сама СУБД. Сборка от 1С - бесплатно при действующем ИТС. Postgres Pro - платно, по прайсу вендора, зависит от редакции и числа ядер. Для малого бизнеса первый вариант закрывает вопрос полностью.

Операционная система. Если заодно переезжаете на Linux - экономите на лицензии Windows Server. Если остаетесь на Windows - тут без изменений.

Работы по миграции. Основная статья расходов. Зависит от того, типовая у вас конфигурация или доработанная, и насколько плотно вы завязаны на COM и внешние компоненты.

Оптимизация после переезда. Вот это регулярно забывают заложить в бюджет, а зря. Часть запросов, которые на MS SQL летали, на PostgreSQL начнут тормозить. Их придется переписывать. Чем больше доработок в конфигурации - тем больше этой работы.

Обучение или найм. Кто-то должен уметь это администрировать. Либо учите своего, либо берете на обслуживание.

Чтобы было понятно про порядок цифр - как это обычно выглядит.

Типичный переезд, на который зовут: база 80-150 гигабайт, 20-40 пользователей, конфигурация типовая или с небольшими доработками. Такая миграция занимает две-четыре недели от инвентаризации до переключения, и большая часть этого времени - не перенос данных, а прогон на тестовом стенде и разбор того, что просело.

Сам перенос - это одна ночь. Иногда выходные, если база большая.

А вот чего почти никто не закладывает в бюджет: доработку запросов после переезда. Часть отчетов, которые на MS SQL строились нормально, на PostgreSQL начинают тормозить - и их приходится переписывать. Чем больше в конфигурации самописного, тем больше этой работы. На типовой ее почти нет, на сильно доработанной она может занять больше, чем сама миграция.

Поэтому когда спрашивают "сколько будет стоить переезд", честный ответ начинается с вопроса "а сколько у вас доработок".

Порядок миграции

Коротко, по шагам. Подробный разбор каждого - тема отдельной статьи.

Шаг 1. Инвентаризация. Размер базы, число пользователей, список доработок, внешние обработки, обмены, COM-компоненты. Здесь становится понятно, миграция это или переписывание.

Шаг 2. Тестовый стенд. Обязательно. Отдельная машина, правильная сборка PostgreSQL, настроенный конфиг.

Шаг 3. Перенос копии. Выгрузка из MS SQL в .dt, загрузка в PostgreSQL. На больших базах долго, планируйте время.

Шаг 4. Прогон. Реальные операции реальными людьми на тестовой базе. Закрытие месяца, тяжелые отчеты, все обмены. Здесь вылезет то, что не вылезло бы никогда на синтетике.

Шаг 5. Замер и оптимизация. Сравниваете время ключевых операций с MS SQL. Что просело - разбираете и чините. Вот этот шаг нельзя пропускать, и именно его чаще всего пропускают.

Шаг 6. Настройка бэкапов и мониторинга. До переключения, не после.

Шаг 7. Переключение. В выходные, со старой базой наготове на случай отката.

Шаг 8. Наблюдение первый месяц. Autovacuum, раздувание, время отклика. Первые недели покажут, что настроено криво.

Мой вывод

Резюмирую свою позицию, раз с нее начал.

MS SQL мне по-прежнему нравится больше. Удобнее администрировать, предсказуемее планировщик, инструменты зрелее. Если у вас он есть, лицензии в порядке, версия поддерживается - не трогайте. Работающую систему меняют по причине, а не по моде.

Но реальность такова, что дорога в основном односторонняя. Новых лицензий не купить, версии выходят из поддержки одна за другой, Express упирается в свой потолок. Рано или поздно вопрос встанет почти перед всеми.

И вот когда он встанет - PostgreSQL это нормально. Не лучше. Нормально. При двух условиях, которые я повторю в третий раз, потому что они решают все: правильная сборка и настроенный конфиг.

Девять из десяти историй "мы переехали и все стало тормозить" - это ванильный постгрес с дефолтными настройками. Не архитектура виновата. Виновата установка в три клика и уверенность, что на этом все.

А раз переезд все равно предстоит - лучше делать его спокойно, на тестовом стенде, когда никто не горит, чем в аврале после того, как что-то отвалилось =P

Если нужна помощь

Как вы помните, я айти-специалист: собираю и настраиваю серверы, веду 1С для организаций.

Чем помогаем:

• считаем, надо ли вам вообще переезжать - и говорим "не надо", если не надо. Это бывает чаще, чем кажется;
• разворачиваем PostgreSQL правильно - официальная сборка, конфиг под вашу нагрузку и число пользователей, а не по умолчанию;
• переносим базу с прогоном на тестовом стенде до переключения;
• оптимизируем то, что просело после переезда - запросы, индексы, настройки автоочистки;
• настраиваем бэкапы и мониторинг - pg_probackup, архив WAL, уведомления об ошибках;
• сдаем в аренду серверы с поддержкой, где все это уже развернуто и обслуживается без вашего участия.

Подробнее про обслуживание: 1c.akernel.ru/services/it-podderzhka

Группа по 1С: https://t.me/russia1c_corp

Напишите размер базы, число пользователей и версию MS SQL - скажу, стоит ли вам дергаться в принципе. Бесплатно и без "вам срочно надо мигрировать")

Читайте также: Какой сервер нужен под 1С, 1С тормозит: диагностика за 30 минут и Ваш бэкап 1С точно рабочий?

Источники: системные требования 1С по СУБД (v8.1c.ru), даты окончания поддержки Microsoft SQL Server, Указ Президента РФ № 166 и решение о переносе сроков перевода значимых объектов КИИ.