Как выбрать СУБД для 1С без дорогой ошибки

Для 1С выбирайте СУБД по совместимости с вашей платформой и доступной экспертизе. PostgreSQL не требует лицензии самой СУБД, но нужна поддерживаемая сборка и администрирование; SQL Server требует учесть лицензионную модель. Ниже — что я проверяю до решения и переноса.

Когда 1С нужна клиент-серверная СУБД

У 1С есть файловый и клиент-серверный варианты. Второй нужен не «после нескольких пользователей», а когда этого требуют нагрузка, режим работы и требования к эксплуатации. В клиент-серверном варианте данные обслуживает отдельная СУБД; среди поддерживаемых платформой вариантов — Microsoft SQL Server и PostgreSQL, а также другие системы из перечня 1С. Для малого офиса часто сравнивают именно первые две: привычную коммерческую СУБД и PostgreSQL без лицензионной платы за сам продукт. Это не делает их взаимозаменяемыми: отличаются требования к совместимым версиям, эксплуатации и компетенциям. Перед выбором я проверяю настройку 1С на Linux только если такой вариант вообще рассматривается. СУБД выбирают под конкретную платформу и работу, а не по симпатии к логотипу.

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

Кейс «Корешок»: бюджет против привычки

Возьмём условный пример из brief — архивно-переплётную мастерскую «Корешок» на 14 рабочих мест. Это иллюстрация выбора, а не опубликованный замер производительности или коммерческое предложение. В исходном сценарии база выросла из файлового режима, и администратор предложил SQL Server Standard: он знаком с Windows и привычными инструментами. Но до выбора надо посчитать стоимость лицензирования под реальную конфигурацию и правила поставки, а не просто умножить число сотрудников на цену из первой поисковой выдачи. Для SQL Server Standard возможны модели Server + CAL и Per Core; Server + CAL включает серверную лицензию и CAL SQL Server на каждого пользователя или устройство доступа. Это не Windows Server CAL — путать их дорого.

В условном расчёте команда сравнила эту сумму с PostgreSQL и стоимостью сопровождения. PostgreSQL распространяется без платы за лицензию СУБД, но само внедрение, резервное копирование, обновления и дежурство администратора бесплатными от этого не становятся. В примере у мастерской есть Windows-опыт, но мало опыта с PostgreSQL; поэтому мы закладываем обучение и помощь на старте, а не выдаём неизвестную экономию за факт. Решение в пользу PostgreSQL имеет смысл, если конкретная платформа и сборка совместимы, а ответственность за эксплуатацию назначена. «Сэкономили на лицензии» — ещё не итоговый расчёт. Отдельно согласуем окно работ, контрольную копию и критерии приёмки: открываются ли нужные разделы, проходят ли типовые операции, совпадают ли ключевые остатки и документы. Если эти проверки не определены, спор о скорости превращается в спор впечатлений. Я не обещаю универсальный срок: он зависит от объёма базы, доступности специалистов и результата тестового переноса.

• Условный пример: 14 рабочих мест.
• Сверить модель лицензирования SQL Server Standard.
• Проверить совместимость PostgreSQL с платформой и ОС.
• Заранее назначить ответственного за сопровождение.

Лицензии: что сравнивать в смете

PostgreSQL не требует оплаты лицензии самой СУБД, однако остаются работы по установке и сопровождению, инфраструктура и стоимость простоя. SQL Server Standard лицензируется по одной из доступных моделей: Server + CAL или Per Core. Для Server + CAL нужны лицензия сервера и CAL SQL Server каждому пользователю или устройству, обращающемуся к экземпляру; при Per Core считают ядра по условиям Microsoft. Нельзя честно назвать, что выгоднее для 14 рабочих мест, не зная числа ядер, виртуализации, редакции, договора и условий покупки. Считайте оба варианта по актуальным условиям лицензирования и включайте в сравнение поддержку.

В смету PostgreSQL я тоже включаю не только установку: тестовый перенос, проверку типовых операций, план восстановления, мониторинг и время специалиста. Для сравнения полезны три строки: лицензии СУБД, первичная настройка и регулярное сопровождение. Так видно, что именно оплачивается и кто отвечает за результат. В конфигураторе 1С выбирают клиент-серверный вариант и конкретную СУБД; это не исправляет несовместимую версию и не переносит данные само по себе. В «Корешке» решение принимается после такого расчёта и сверки платформы. Никаких «сотен тысяч экономии» без коммерческих условий — в статье это были бы цифры с потолка. Если в проекте сравнивают только цену лицензии, я прошу показать расчёт вместе с расходами на администрирование за выбранный период. Не обязательно строить сложную финансовую модель: достаточно явно записать предположения и отдельно отметить разовые работы. Для оценки PostgreSQL полезно заранее посмотреть настройки PostgreSQL для 1С, но параметры из чужого примера не копировать без измерений.

Кто будет администрировать выбранную СУБД

СУБД должна быть знакома тому, кто отвечает за её обновление, журналы, доступы, резервные копии и восстановление. Администратору SQL Server пригодятся навыки работы с Windows и средствами самой СУБД; с PostgreSQL надо освоить её роли и конфигурацию, обслуживание таблиц и диагностику. Это не война операционных систем. PostgreSQL может работать в разных поддерживаемых окружениях, и проверять нужно именно выбранную связку версий, а не стереотип про обязательный Linux. В моих проектах я спрашиваю: кто заметит нехватку места, кто проверит журнал ошибки и кто восстановит базу ночью? Если ответ «разберёмся потом», план ещё не готов.

В PostgreSQL параметры shared_buffers, work_mem и maintenance_work_mem не стоит копировать из чужого файла как рецепт. Они влияют на разные виды потребления памяти и требуют настройки под сервер и профиль нагрузки; work_mem может расходоваться несколькими операциями и соединениями. Я начинаю с наблюдений и документации, меняю ограниченное число настроек, затем проверяю поведение на тестовой нагрузке. Для SQL Server тоже нужны проверка конфигурации и мониторинг — привычный интерфейс не превращает его в систему без обслуживания. В мастерской из примера мы бы сначала назначили ответственного и проверили компетенции, и лишь затем утвердили перенос. Регулярная проверка должна отвечать на практические вопросы: какие метрики собираются, кто получает уведомление и что он делает при заполнении диска или росте задержек. Для 1С удобно смотреть не только на СУБД, но и на сервер приложений; пример состава наблюдения разобран в материале о мониторинге 1С. Одна цифра CPU не объяснит, почему пользователю долго открывается документ.

• MS SQL: привычный интерфейс, Windows-администраторы, дорогая лицензия.
• PostgreSQL: командная строка, Linux-навыки, бесплатная лицензия.
• Риск: отсутствие знаний по автовакууму и правам доступа в PostgreSQL.
• Решение: обучение персонала или привлечение аутсорсера.

Резервные копии: проверяйте восстановление

У резервной копии есть смысл только вместе с проверенным сценарием восстановления. Для PostgreSQL логическая копия базы создаётся, например, pg_dump; в архивных форматах для восстановления применяется pg_restore. Это не универсальная замена физическому резервному копированию и архивированию WAL, если нужны восстановление на момент времени и нужные показатели потери данных. Выбор зависит от размера базы, допустимого простоя и требований к точке восстановления. В документации PostgreSQL отдельно описаны логический дамп и физическое резервирование — не смешивайте эти методы в одной фразе «у нас есть бэкап».

Я прошу зафиксировать расписание копирования, хранение отдельной копии и регулярную проверку восстановления в тестовой среде. Частоту определяют допустимая потеря данных и время восстановления, а не календарная примета «раз в квартал». В условном сценарии «Корешка» можно начать с ежемесячной проверки, но это пример рабочего процесса, а не норматив для всех. Перед тестом фиксируем, какую копию и на какую дату восстанавливаем, сколько это занимает и запускается ли после этого база 1С. Без такой проверки зелёная галочка задания говорит лишь о том, что программа что-то сделала. Если нужна копия только для переноса или ручной выгрузки, логический дамп может подойти; для большой базы и малой допустимой потери данных выбирают другой план. В любом случае держите копию отдельно от исходного хранилища и учитывайте доступность архивов WAL, если опираетесь на восстановление к моменту времени. Практический порядок аварийного восстановления 1С разобран в статье о восстановлении базы 1С.

Производительность: сначала измерения, потом железо

Скорость 1С определяется конфигурацией, запросами, сервером приложений, СУБД, памятью и дисковой подсистемой. Число рабочих мест само по себе не даёт формулу для объёма RAM или параметров PostgreSQL. В первоначальном тексте было заявлено, что 16 ГБ дали результат лучше файловой базы; подтвердить этот замер нечем, поэтому я убираю его как доказательство. Для «Корешка» я бы сравнил повторяемые операции на тестовой копии до и после переноса, зафиксировал время ответа и нагрузку на CPU, память и диски. Сравнение с MS SQL имеет смысл только при одинаковых данных и сопоставимой нагрузке.

Автовакуум и статистика PostgreSQL важны для штатного обслуживания, но один тумблер не объясняет любое замедление. Сначала найдите узкое место: длительные запросы, блокировки, нехватка памяти, задержки ввода-вывода или перегруженный сервер приложений. Затем меняйте конкретную причину и измеряйте повторно. Не требуйте выделенный LUN как универсальное условие работы: тип хранилища выбирают по нагрузке, отказоустойчивости и требованиям СУБД, а не по модному слову в смете. В этой статье нет универсального рецепта железа — есть последовательность измерений до покупки. Наблюдения записывайте до и после изменений: версия платформы и СУБД, время контрольных операций, нагрузка и объём данных. Тогда следующий специалист увидит не «вчера стало хуже», а последовательность измерений. Перед изменением конфигурации сохраняйте исходные значения и план отката. Так можно понять эффект отдельной настройки, а не приписывать случайное улучшение последнему изменению.

• PostgreSQL требует ручной настройки параметров памяти.
• MS SQL часто работает «из коробки» на Windows.
• Критичен диск: выделенные диски или LUN для СУБД.
• Мониторинг задержек I/O обязателен для обеих систем.

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