Массовый уход западных СУБД и переход на отечественные решения (Postgres Pro, Red Database, Arenadata DB) стал одним из главных вызовов для владельцев 1С в 2024–2025 гг. К апрелю 2026 года большинство компаний уже провели миграцию, но далеко не все осознали её последствия. Типичная картина: «всё работает, но как-то медленнее», «отчёты стали грузиться на 15–30 секунд дольше», «утром база падает при первом запуске».
Аудит 1С сегодня — это не поиск ошибок в конфигурации, а системная проверка того, как именно ваша база живёт на новой СУБД. И вот что изменилось.
План запросов больше не тот
На Microsoft SQL Server многие запросы в 1С строились оптимально за счёт «привычки» оптимизатора. На Postgres Pro (даже с расширением 1С) план выполнения может кардинально отличаться. При аудите мы регулярно находим:
- Сканирование всей таблицы там, раньше был поиск по индексу;
- Неправильный порядок соединения нескольких больших таблиц (например, «Документы.Реализация» и «РегистрыНакопления.Продажи»);
- «Раздувание» временных таблиц в сотни миллионов записей, о чём SQL Server просто молчал.
Что проверять при аудите: Соберите статистику по 5–10 самым медленным отчётам. Выполните EXPLAIN ANALYZE и сравните фактическое число строк с ожидаемым. Если расхождение >10 раз — индекс либо сломан, либо не используется.
Блокировки стали заметнее
Postgres Pro использует другую модель многоверсионности (MVCC), чем MS SQL. В 1С это вылилось в новые типы блокировок:
transaction id wraparound— база резко тормозит раз в несколько месяцев;- накопление «мёртвых кортежей» при частых проведениях документов (обычная операция в 1С, но на новой СУБД требует регулярного
VACUUM); - длительные транзакции в фоне (например, регламентное задание, которое «забыли» переписать под PostgreSQL).
Кейс из апреля 2026: У производственной компании после перехода на Red Database отчёты по складу стали строиться по 2 минуты вместо 10 секунд. Аудит показал: фоновое обновление итогов захватывало блокировку на 5 минут, а 1С продолжала держать транзакцию. Лечение — разбивка регламентного задания на пакеты по 1000 записей.
Параметры сервера, о которых вы не знали
На MS SQL достаточно было выделить память и всё. На Postgres Pro критически важны:
shared_buffers(обычно ставят слишком мало — 25% от ОЗУ вместо 40%);effective_cache_size(почти всегда занижен);work_mem— если оставить по умолчанию 4 МБ, сортировки в 1С будут ползти.
При аудите мы измеряем: Скорость выполнения типовой операции «Закрытие месяца» до и после тюнинга. Разница в 3–5 раз — норма для 2026 года.
Адаптация кода 1С — обязательна
Миф: «достаточно перенести базу, и 1С сама подстроится». Нет. При аудите обязательно выявляются:
ВЫБРАТЬ *вместо перечисления полей (на PostgreSQL это больнее);- отсутствие индексов на полях, по которым идёт соединение виртуальных таблиц;
- массовые записи в регистры внутри цикла — теперь это убивает производительность.
Практический вывод: После миграции нужен не косметический аудит, а профилирование каждого тяжёлого отчёта в режиме реальной СУБД.
Что делать прямо сейчас?
- Запустите мониторинг длительных запросов (например, через
pg_stat_statements). - Сравните время «Закрытия месяца» до миграции и сейчас — если разница >30%, вызывайте аудит.
- Проверьте настройки автоочистки (
autovacuum) — на многих серверах она отключена или работает некорректно.
Аудит 1С на Postgres Pro / Red Database в 2026 году — это не роскошь, а экономия. Одна незамеченная блокировка на складе может стоить часов простоя отдела отгрузки. Один неправильный план запроса — ежедневных сбоев отчёта для ФНС.
Мы при аудите не просто даём отчёт. Мы показываем конкретные запросы, исправляем их и настраиваем СУБД так, чтобы 1С летала быстрее, чем на старом SQL Server. Проверьте свою миграцию — возможно, она ещё не завершена.
