PostgreSQL под сервер 1С: на какой версии остановиться и как на неё перейти

Для нового сервера 1С 8.3 берите самую свежую версию PostgreSQL, для которой есть сборка с патчами 1С и которую ваша версия платформы указывает в системных требованиях. Сегодня это обычно 16 или 17. Версию 14 стоит оставить только там, где обновить платформу нельзя: в ноябре 2026 года сообщество прекращает её поддержку.

Частое заблуждение — поставить «чистый» PostgreSQL с официального сайта проекта и подключить к нему 1С. Так не выйдет: платформе нужны расширения mchar, fulleq и ряд патчей, которых в стандартном дистрибутиве нет. Выбор версии PostgreSQL для 1С — это всегда выбор сборки, а не только номера.

Что платформа 1С требует от СУБД

Платформа работает с PostgreSQL только в клиент-серверном варианте. Файловой базе СУБД не нужна, и переводить её «под PostgreSQL» без сервера 1С бессмысленно.

Подходят три вида сборок:

• 🟢 Сборки PostgreSQL от фирмы 1С. Распространяются через сайт обновлений для пользователей с договором сопровождения. Есть версии под Linux и Windows.
• 🟢 Сборки Postgres Professional для 1С. Бесплатная редакция с теми же расширениями, плюс коммерческие Postgres Pro Standard и Enterprise.
• 🔴 Ванильный PostgreSQL. Без патчей 1С база не создастся или будет работать с ошибками сравнения строк.

Список поддерживаемых версий СУБД указан в системных требованиях каждой версии платформы на releases.1c.ru. Принцип простой: новая версия PostgreSQL появляется в требованиях с некоторым отставанием, а старые оттуда постепенно уходят.

Что проверить перед выбором

1. Номер платформы на сервере 1С — в окне «О программе» или в свойствах службы 1C:Enterprise 8.3 Server Agent.
2. Операционную систему сервера СУБД. Под Linux выбор сборок шире, и большинство рекомендаций по настройке писались под него.
3. Требования конфигураций. Свежие релизы БП, ЗУП и ERP требуют свежую платформу, а она, в свою очередь, ограничивает список СУБД.
4. Есть ли у вас лицензия на Postgres Pro, если нужна редакция Enterprise.

Как узнать, какая версия стоит сейчас

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

SELECT version();
SHOW server_version;

Первый запрос покажет полную строку с номером, компилятором и разрядностью, второй — только номер вида 15.8. Первая цифра — мажорная версия, вторая — корректирующий выпуск.

Корректирующие выпуски внутри одной мажорной версии ставятся простым обновлением пакетов, без миграции данных. Их стоит ставить регулярно: в них закрывают ошибки и уязвимости. Перед обновлением пакетов остановите службу 1С или заблокируйте сеансы — перезапуск СУБД оборвёт работу пользователей.

Если в выводе встречается упоминание Postgres Pro или сборки 1С, у вас правильный дистрибутив. Если строка «голая», проверьте список расширений командой \dx в psql, подключившись к базе 1С: там должны быть mchar и fulleq.

Версии 14, 15, 16 и 17 в задачах 1С: в чём разница

Прироста «в разы» от смены версии ждать не стоит. 1С генерирует однотипные запросы, и узкие места чаще в настройках, дисках и временных таблицах, а не в номере СУБД. Но каждая версия что-то добавляет.

Для баз 1С особенно заметны изменения в очистке. 1С много пишет в регистры и активно создаёт временные таблицы. Из-за этого системный каталог и таблицы итогов быстро обрастают «мёртвыми» строками. Версии 16–17 справляются с этим спокойнее, особенно на базах от сотни гигабайт.

Инкрементные копии в 17-й версии полезны для больших баз. Полная копия ERP на 500 ГБ идёт часами, а инкремент за сутки — заметно быстрее.

Как 1С подключается к PostgreSQL и при чём тут ODBC

ODBC-драйвер серверу 1С не нужен. Рабочие процессы rphost подключаются к PostgreSQL напрямую по родному протоколу СУБД через библиотеку libpq. Она входит в поставку платформы.

Поэтому совместимость проверяется не по драйверу, а по паре «версия платформы — версия СУБД». ODBC может понадобиться только сторонним программам: отчётным системам, BI или внешним обработкам, которые читают таблицы базы напрямую. Для них ставьте драйвер psqlODBC не ниже версии сервера СУБД.

Как кластер 1С связан с сервером СУБД

• 🔹 Клиент обращается к агенту сервера 1С (порт 1540), затем к менеджеру кластера (1541) и рабочим процессам.
• 🔹 Рабочий процесс сам открывает соединение с PostgreSQL на порт 5432 или тот, что указан.
• 🔹 Параметры подключения задаются в свойствах информационной базы в консоли кластера: тип СУБД, сервер баз данных, имя базы, пользователь и пароль.

Если на одном сервере работают две версии PostgreSQL на разных портах, порт пишут прямо в поле «Сервер баз данных»:

127.0.0.1 port=5433

Так удобно переводить базы по одной: старая СУБД продолжает работать на 5432, новая принимает базы на 5433.

Чем грозит устаревшая версия СУБД

Устаревшая версия редко ломается в один день. Проблемы копятся постепенно.

• ⛔ Нет исправлений безопасности. После окончания поддержки уязвимости в старой версии больше не закрывают. Для сервера, где лежит бухгалтерия, это неприемлемо.
• ⛔ Платформу нельзя обновить. Новые версии 1С перестают поддерживать старые СУБД. Следом встают конфигурации: свежий релиз БП или ЗУП требует свежую платформу.
• ⛔ Не поставить на новую ОС. Пакеты старых версий не собираются под свежие дистрибутивы Linux, и сервер «застывает» на старой системе.
• ⛔ Медленная очистка. На больших базах таблицы растут быстрее, чем их чистит autovacuum старой версии, и запросы постепенно замедляются.

Отдельный случай — версии 9.6–12. Их до сих пор встречают на серверах, которые настроили много лет назад и забыли. Поддержка этих версий закончилась давно, а переход с них обычно требует и обновления платформы. Такой переезд планируют как проект с тестовым прогоном, а не как вечернее обновление.

Переход на новую версию PostgreSQL: порядок действий

Обновить PostgreSQL «поверх» между мажорными версиями нельзя: формат файлов данных у 15 и 16 разный. Нужна миграция. Способов три.

Подготовка

1. Проверьте, что ваша платформа поддерживает целевую версию PostgreSQL. При необходимости сначала обновите платформу.
2. Сделайте полную резервную копию: дамп СУБД и выгрузку .dt для страховки.
3. Прогоните переход на копии базы на тестовом сервере и замерьте время.
4. Согласуйте окно работ: все пользователи должны выйти.

Во время переноса базы в ней никто не должен работать — иначе данные, введённые после копирования, пропадут.

Перенос через pg_upgrade

1. В консоли кластера 1С установите блокировку начала сеансов для базы и дождитесь выхода пользователей. Активные сеансы оборвутся, поэтому делайте это в согласованное время.
2. Поставьте новую сборку PostgreSQL рядом со старой, создайте пустой кластер с той же локалью (для 1С обычно ru_RU.UTF-8).
3. Остановите обе службы PostgreSQL.
4. Запустите проверку совместимости, затем сам перенос:

/usr/lib/postgresql/17/bin/pg_upgrade \
  -b /usr/lib/postgresql/15/bin -B /usr/lib/postgresql/17/bin \
  -d /var/lib/postgresql/15/main -D /var/lib/postgresql/17/main \
  --check

Без ключа --check команда выполнит перенос. Пути зависят от сборки и дистрибутива — проверьте их у себя. Ключ --link ускоряет перенос в разы, но после первого запуска нового кластера к старому вернуться нельзя.

5. Запустите новый сервер и пересоберите статистику:

vacuumdb --all --analyze-in-stages

6. Если порт изменился, поправьте поле «Сервер баз данных» в свойствах базы в консоли кластера и снимите блокировку сеансов.

Перенос через .dt

Создайте в консоли кластера новую базу на новом сервере СУБД, затем загрузите в неё выгрузку через Конфигуратор: Администрирование → Загрузить информационную базу. Способ медленный, зато не зависит от версий и расширений PostgreSQL.

Настройки postgresql.conf под нагрузку 1С

Сборки для 1С ставятся с разумными значениями, но под конкретный сервер их нужно подогнать. Ниже — ориентиры для выделенного сервера СУБД с 64 ГБ памяти и SSD.

shared_buffers = 16GB              # около 25% памяти
effective_cache_size = 48GB        # около 75% памяти
work_mem = 64MB
maintenance_work_mem = 2GB
temp_buffers = 256MB               # 1С активно использует временные таблицы
max_connections = 500
max_locks_per_transaction = 256
random_page_cost = 1.1             # для SSD
effective_io_concurrency = 200     # для SSD
max_wal_size = 16GB
checkpoint_completion_target = 0.9
from_collapse_limit = 20
join_collapse_limit = 20
autovacuum_max_workers = 4
autovacuum_naptime = 20s

Почему именно так:

• 📌 work_mem выделяется на каждую операцию сортировки в каждом соединении. При 500 соединениях большое значение быстро съедает память. Поднимайте осторожно.
• 📌 max_locks_per_transaction — 1С в одной транзакции трогает много таблиц. Со значением по умолчанию (64) на больших проведениях встречается ошибка нехватки общей памяти для блокировок.
• 📌 from_collapse_limit и join_collapse_limit — запросы 1С соединяют много таблиц. При лимите по умолчанию (8) планировщик перестаёт перебирать порядок соединений и иногда строит плохой план.
• 📌 online_analyze — расширение из сборок для 1С. Оно обновляет статистику по временным таблицам сразу после их заполнения. Проверьте, что оно подключено в shared_preload_libraries и включено.

Применить изменения shared_buffers и max_connections можно только перезапуском службы. Перезапуск оборвёт все сеансы 1С, так что делайте его вне рабочего времени.

Как выбрать вариант для своей ситуации

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