PostgreSQL для 1С: настройка, обслуживание и миграция без иллюзий

Переход 1С с MS SQL на PostgreSQL перестал быть экзотикой: компании массово мигрируют - из-за стоимости лицензий и санкционных рисков. Но у перехода есть побочный эффект, о котором узнают уже после миграции: PostgreSQL - не “то же самое, только бесплатно”. Это другая СУБД с другой архитектурой хранения, другим обслуживанием и другими граблями. Установленный “по умолчанию” и оставленный без настройки, он под нагрузкой 1С обычно работает медленнее того MS SQL, с которого на него ушли.

Ниже - почему бизнес переходит на PostgreSQL, чем его обслуживание принципиально отличается от MS SQL, какие параметры настраивают под 1С (с честной оговоркой “зависит от железа”), на какие грабли наступают при миграции и что смотреть, когда PostgreSQL тормозит. Без обещаний “ускорим в 10 раз”: сначала аудит.

Почему переходят на PostgreSQL

Два реальных драйвера, оба не про производительность.

Лицензии. MS SQL Server лицензируется по ядрам, и на многоядерном сервере под большую базу 1С счёт идёт на серьёзные суммы - плюс лицензии Windows Server. PostgreSQL бесплатен, и для 1С есть как сборки от самой фирмы “1С”, так и патченные сборки (Postgres Pro и сообщество) с нужными расширениями. На большом сервере экономия только на СУБД покрывает бюджет миграции.

Импортозамещение и санкционные риски. Для госсектора и компаний под регуляторными требованиями вопрос стоит жёстко: продлить лицензии MS SQL стало невозможно или рискованно. PostgreSQL с российскими сборками и поддержкой - штатный ответ.

Чего в этом списке нет - так это “PostgreSQL быстрее”. Это первое, что нужно принять: миграция окупается лицензиями и независимостью, а не автоматическим приростом скорости. Скорость - результат настройки, а не смены СУБД.

Бывает и обратный переезд, с PostgreSQL на MS SQL, и у него своя ловушка. При нулевом смещении дат пустые даты 0001-01-01 и 0001-01-02 превращаются в одну и ту же 1753-01-01, а перенос отчитывается успехом, и число строк в таблицах сходится. Что проверить в базе до такого переезда, собрано в проверке перед переносом на MS SQL.

Чем обслуживание отличается от MS SQL

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

MVCC, “мёртвые” строки и autovacuum. Ключевое отличие. В PostgreSQL при обновлении строки старая версия не перезаписывается, а помечается устаревшей (мёртвой) и остаётся в таблице - так работает многоверсионность (MVCC). Эти мёртвые версии должен убирать процесс autovacuum. Если он настроен слабо, а нагрузка на запись высокая (а 1С пишет много - движения регистров, перепроведения, временные таблицы), мёртвые строки копятся быстрее, чем убираются. Таблица и её индексы распухают (bloat), запросы читают всё больше “пустоты”, и база деградирует. В MS SQL такого механизма нет - там нет прямого аналога vacuum, и администратор про него просто не думает. В PostgreSQL забыть про autovacuum - значит гарантированно получить деградацию через несколько месяцев.

Контрольные точки (checkpoints). PostgreSQL периодически сбрасывает изменения из памяти на диск контрольной точкой. Если чекпоинты происходят слишком часто и агрессивно, они дают пиковую нагрузку на диск и “дёргают” отзывчивость базы. Настройка частоты и “размазывания” чекпоинтов по времени - обязательная часть подготовки под 1С, аналога которой в привычках MS SQL-администратора нет.

Статистика и планировщик. PostgreSQL, как и MS SQL, строит планы запросов по статистике распределения данных. После массовых загрузок и закрытий периода статистика устаревает, и планы “слетают” - та же болезнь, что в MS SQL, но с другими инструментами обновления. Для 1С в патченных сборках используется расширение online_analyze, которое обновляет статистику по временным таблицам немедленно, - 1С создаёт их массово, и без свежей статистики планировщик по ним ошибается.

Обслуживание индексов. Индексы в PostgreSQL тоже распухают под нагрузкой на запись и периодически требуют перестроения (REINDEX, желательно CONCURRENTLY, чтобы не блокировать работу). Логика “фрагментации”, привычная по MS SQL, здесь заменяется логикой bloat.

Ключевые параметры под 1С

Сразу дисклеймер, без которого этот раздел вреден: конкретные значения зависят от железа - объёма оперативной памяти, числа ядер, типа дисков, числа одновременных сессий и профиля нагрузки. Ниже - не “пропишите это”, а “вот что настраивают и по какой логике”. Слепое копирование чужого postgresql.conf - частая причина, по которой “настроенный по статье из интернета” PostgreSQL тормозит.

Параметр	За что отвечает	Логика подбора
shared_buffers	Память под кэш страниц самой СУБД	Ориентир - около четверти ОЗУ; больше не всегда лучше
effective_cache_size	Оценка, сколько всего памяти под кэш (СУБД + ОС)	Ориентир - около половины-трёх четвертей ОЗУ; влияет на планы, память не резервирует
work_mem	Память на операцию сортировки/соединения в запросе	Умножается на число операций и сессий - легко переоценить и уйти в своп
maintenance_work_mem	Память под vacuum, создание индексов	Больше ускоряет обслуживание; autovacuum не берёт свыше ~1 ГБ
temp_buffers	Память под временные таблицы сессии	Для 1С важнее, чем кажется: временных таблиц много
max_connections	Предел одновременных подключений	Не завышать: каждое соединение - процесс и память; при большом числе сессий - пул
autovacuum-группа	Агрессивность уборки мёртвых строк	Под запись 1С обычно делают агрессивнее заводских значений

Отдельно - обязательные для 1С параметры совместимости, которые к производительности отношения не имеют, но без которых 1С либо работает неверно, либо медленно: standard_conforming_strings = off, escape_string_warning = off, max_locks_per_transaction (поднимают, ориентир - от 150-256, у 1С много блокировок на транзакцию), row_security = off. Плюс расширения из патченных сборок: online_analyze (статистика по временным таблицам) и plantuner (подсказки планировщику). Эти вещи не подбираются “по вкусу” - они либо стоят правильно, либо база ведёт себя странно.

Главная ошибка при настройке памяти - сложить shared_buffers + work_mem × (пиковое число операций и сессий) + прочее и получить больше, чем есть физической памяти. Тогда под пиковой нагрузкой сервер уходит в своп, и “оптимизированная” база начинает тормозить сильнее ненастроенной. work_mem коварен именно тем, что он на операцию, а не на сервер: тяжёлый запрос с несколькими сортировками у сотни сессий умножает его в сотни раз.

Грабли миграции MS SQL → PostgreSQL

Что ломается или разочаровывает при переносе, если готовиться к нему как к “просто смене движка”.

• Скорость сразу после переноса - хуже, а не лучше. Свежемигрированная база на дефолтном postgresql.conf почти всегда медленнее исходного MS SQL. Это норма промежуточного состояния, а не провал миграции: до настройки параметров, обновления статистики и обкатки autovacuum судить о производительности рано.
• Регистр и кодировки. Разница в сортировке строк (collation), поведении с регистром, работе с датами всплывает на конкретных отчётах и отборах. Проверять нужно данными, а не “вроде открылось”. Отдельная засада тут - сам перенос: PostgreSQL сравнивает строки через ICU и считает равными пары, которые MS SQL различает (неразрывный пробел и обычный, № и No), из-за чего уникальный индекс на приёмнике не создаётся и ibcmd встаёт молча. Как найти такие строки до окна переезда - разобрано в статье “Миграция 1С на PostgreSQL: как проверить базу заранее”.
• Зависимость от версии платформы и сборки. PostgreSQL для 1С - это не любой ванильный PostgreSQL, а совместимая версия из патченной сборки. Взять свежий community-релиз “потому что новее” - путь к тонким несовместимостям. Версию СУБД сверяют с требованиями конкретной версии платформы 1С. Если версии источника и приёмника разошлись в обратную сторону и выгрузку старшей надо залить в младшую, штатный pg_restore приёмника архив не прочитает, обход разобран в статье “Перенос базы 1С с PostgreSQL 18 на 17”. Требования при этом двигаются: в 8.5.1 из поддержки вышли все версии PostgreSQL до 9.6 включительно, и выясняется это лучше до обновления платформы - что ещё меняется на этом переходе, разобрано в статье “Переход на 1С 8.5: что проверить в конфигурации и на серверах”.
• Локаль кластера и настройки сервера при переезде на Linux. Пакет инициализирует кластер сам и берёт системную локаль, а на свежей Ubuntu это en_US.UTF-8: сортировка строк в русской базе пойдёт по чужим правилам, и заметят это через месяц по странному порядку в отчёте. Туда же ноль шрифтов в минимальной Ubuntu Server и work_mem от автотюнера, не сверенный с max_connections. Разбор с командами - в статье “Перенос 1С на Linux и PostgreSQL: восемь ловушек”.
• Autovacuum не настроили - деградация отложенная. Самая коварная грабля: сразу после миграции всё работает, а через два-три месяца интенсивной записи база распухает от bloat и замедляется. Внешне - “PostgreSQL плохой”, по факту - не настроили уборку.
• Отсутствие обслуживания как процесса. На MS SQL часто жил план обслуживания (пусть и кривой). На новом PostgreSQL его нередко просто нет - ни регулярного REINDEX, ни контроля bloat, ни проверенных бэкапов. Инфраструктура обслуживания переносится не автоматически.

Когда PostgreSQL тормозит: что смотреть

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

1. Bloat таблиц и индексов. Первое подозрение. Оценить раздувание, проверить, справляется ли autovacuum, при необходимости - усилить его и провести VACUUM/REINDEX. Распухшая от мёртвых строк таблица - самая частая причина “PostgreSQL внезапно стал медленным”.
2. Планы запросов (EXPLAIN ANALYZE). Аналог планов MS SQL. Показывает, где идёт последовательное сканирование вместо индекса, где планировщик ошибся в оценке из-за устаревшей статистики.
3. Статистика и online_analyze. Проверить, обновляется ли статистика, особенно по временным таблицам, которых у 1С много. Слетевшая статистика → неверные планы → сканирования.
4. Настройки памяти. Не ушёл ли сервер в своп из-за завышенного work_mem × число сессий; хватает ли shared_buffers и temp_buffers.
5. Чекпоинты и диск. Слишком частые агрессивные чекпоинты дают пиковую нагрузку на диск и “рывки” отзывчивости.
6. Блокировки и долгие транзакции. “Зависшая” старая транзакция мешает autovacuum убирать мёртвые строки во всей базе - одна забытая открытая транзакция способна раздуть базу целиком.

Как и на MS SQL, ключевой принцип: разделить “медленно” (сервер работает, грузит CPU или диск) и “висит” (стоит на блокировке, ничего не делая) - это разные болезни с разным лечением. Общий подход к диагностике тормозов, применимый к обеим СУБД, мы разбирали в статье “1С тормозит: что делать”.

Коротко

На PostgreSQL переходят ради лицензий и импортозамещения, а не ради скорости: без настройки он под нагрузкой 1С обычно медленнее MS SQL, с которого ушли. Главное отличие в обслуживании - модель MVCC: PostgreSQL накапливает “мёртвые” версии строк, которые должен убирать autovacuum, иначе база распухает (bloat) и деградирует через несколько месяцев после миграции. Настройка сводится к параметрам памяти (shared_buffers, work_mem, temp_buffers - с оглядкой на физическую память и число сессий), обязательным параметрам совместимости 1С (standard_conforming_strings, max_locks_per_transaction, расширения online_analyze и plantuner) и агрессивному autovacuum. Все конкретные значения зависят от железа - чужой postgresql.conf копировать нельзя. PostgreSQL после правильной настройки уверенно тянет боевую 1С; “из коробки” - почти гарантированно тормозит.

Если планируете переход на PostgreSQL или он уже тормозит после миграции - мы делаем оптимизацию 1С на обеих СУБД: диагностика по планам запросов и статистике ожиданий, настройка параметров под ваше железо, разбор bloat и autovacuum. Регулярную часть - бэкапы, контроль bloat, обслуживание индексов и статистики - закрывает обслуживание баз 1С: мы настраиваем и MS SQL, и PostgreSQL, включая саму миграцию с одного на другой. А оценить состояние базы и прикинуть эффект перехода без обязательств можно с бесплатного экспресс-аудита.