1С на PostgreSQL вместо MS SQL: когда миграция окупается

Раз в пару месяцев мне звонит очередной директор и спрашивает: а правда что можно 1С посадить на бесплатную базу данных и сэкономить на лицензии MS SQL Server? Отвечаю честно: правда, но не всегда и не для всех. За десять с лишним лет мы в АйТи-Фреш перевели на PostgreSQL полтора десятка баз — где-то это дало экономию в 600-800 тысяч рублей сразу, а где-то я сам отговорил клиента, и он мне потом спасибо сказал. Расскажу, как считать выгоду и какие конфигурации 1С реально уживаются с постгресом, а какие лучше не трогать.

Сколько на самом деле стоит лицензия MS SQL Server

Когда мы ставим клиенту сервер под 1С, львиная доля сметы уходит вовсе не на железо. Windows Server стоит своих денег, но по-настоящему кусается именно MS SQL Server. Лицензия Standard на сервер с четырьмя ядрами сейчас обходится в 600-800 тысяч рублей — и это без учёта того, что цены на софт после ухода Microsoft из России выросли в полтора-два раза, потому что покупать приходится через параллельный импорт. Добавьте CAL на каждое рабочее место — по 25-30 тысяч за штуку — и для конторы на 20 человек набегает ещё полмиллиона.

У меня есть клиент, стоматологическая сеть на восемь кресел, где бухгалтер до сих пор работает в файловой базе 1С — просто потому что директор один раз увидел смету на MS SQL и решил, что подождём. Ждут уже три года. И правильно делают, кстати — там реально нет объёма, который требует серверной СУБД. А вот когда база растёт, файловый режим начинает тормозить, и вопрос лицензии встаёт ребром.

Где реальная экономия, а где её нет

PostgreSQL сам по себе бесплатный — это правда, и на этом многие консультанты строят красивую презентацию. Но 1С официально работает не с ванильным постгресом, а со специальной сборкой — 1С:Предприятие для PostgreSQL, это форк PostgresPro с патчами под нужды платформы. Она тоже бесплатная для установки, но фирма 1С продаёт подписку на техподдержку — что-то в районе 15-20 тысяч рублей в год для небольшой компании. Сравните это с 600-800 тысячами за MS SQL. Разница огромная, даже если накинуть на миграцию работы программиста.

У одной юрфирмы на 15 рабочих мест мы посчитали так: MS SQL Standard плюс CAL — это 950 тысяч рублей единоразово. PostgreSQL плюс подписка на три года — 60 тысяч рублей плюс наши работы по переносу базы, 45 тысяч. Итого экономия почти 850 тысяч. Директор, услышав цифры, сначала не поверил и попросил перепроверить дважды.

Когда миграция реально окупается

Тут я всегда советую не гнаться за экономией ради экономии. Смотрим на три вещи: сколько сейчас стоила бы лицензия MS SQL, если покупать её с нуля; сколько будет стоить сама миграция с учётом простоя; и насколько база чувствительна к нагрузке. Если у клиента уже куплена и оплачена лицензия MS SQL — тогда переход обычно не имеет смысла, разве что заканчивается срок Software Assurance и предстоит новая покупка.

А вот если сервер только разворачивается с нуля, или старая лицензия MS SQL 2008-2012 давно не поддерживается и всё равно нужно что-то покупать — вот тут PostgreSQL почти всегда выигрывает по деньгам. Окупаемость обычно наступает в первый же месяц, потому что сравниваем не абстрактные годы, а разовую покупку лицензии против разовых работ по переносу. Экономия видна сразу в смете, ещё до того, как сервер заработал.

Единственное, что я всегда закладываю в расчёт отдельной строкой — это простой в работе на время миграции. Обычно перенос базы на 20-40 гигабайт занимает вечер пятницы и субботу, но если база большая или конфигурация сильно доработана, закладывайте два-три дня с тестированием. Для торговой компании, которая работает без выходных, это уже статья расходов, и её надо учитывать в смете.

Какие конфигурации 1С хорошо уживаются с PostgreSQL

По моему опыту лучше всего на постгрес переезжают массовые типовые конфигурации без диких доработок: Бухгалтерия предприятия 3.0, Зарплата и управление персоналом, Управление нашей фирмой. Это как раз то, с чем работает большинство моих клиентов — бухгалтерии на аутсорсе, небольшие юрфирмы, медклиники. Объём данных там редко превышает 30-50 гигабайт, нагрузка не бешеная, одновременно работает 5-15 пользователей.

У одной медицинской клиники мы перевели УНФ на постгрес два года назад. База весит 18 гигабайт, работают двенадцать человек — регистратура, бухгалтерия, склад расходников. Летает точно так же, как летала на MS SQL, а иногда даже быстрее, потому что мы заодно почистили индексы и настроили автовакуум. Жалоб не было ни разу.

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

А что лучше не трогать

Есть категория баз, с которыми переезд на постгрес я не советую в принципе — по крайней мере пока. Это крупные ERP и УПП с базой за 150-200 гигабайт, где работает 40-60 одновременных пользователей и крутятся тяжёлые регламентные задания ночью. MS SQL здесь исторически лучше справляется с параллельными блокировками и сложной оптимизацией планов запросов — просто потому что движок под это затачивался десятилетиями плотнее.

Также я бы не спешил, если в компании есть жёсткая интеграция через связанные серверы, SSIS-пакеты или отчёты SSRS, которые тянут данные напрямую из базы 1С. Всё это придётся либо переписывать под постгрес, либо городить костыли — а костыли потом падают в самый неподходящий момент, обычно 31 декабря перед закрытием года.

И ещё момент, о котором мало кто думает: если у вас настроена репликация MS SQL или AlwaysOn для отказоустойчивости — с постгресом это тоже возможно, но настраивается иначе, и специалистов, которые умеют это готовить руками, на порядок меньше на рынке. Если у вас в штате нет своего админа, а обслуживает приходящий специалист раз в месяц — я бы не рисковал.

Как это выглядит на практике — этапы переноса

Сначала мы всегда разворачиваем тестовый стенд и переносим на него копию боевой базы — через выгрузку в dt-файл и загрузку на новый сервер с постгресом. На этом стенде две-три недели идёт параллельное тестирование: закрытие периода, формирование регламентированной отчётности, проведение документов пачками, как в реальной работе. Только когда всё сходится один в один с рабочей базой на MS SQL, назначаем дату переезда.

Сам переезд стараемся ставить на выходные или на праздники — благо в России их достаточно. Отключаем пользователей в пятницу вечером, снимаем финальную выгрузку, разворачиваем на постгресе, прогоняем тестовое закрытие месяца ещё раз, и в понедельник утром люди заходят уже в новую базу, часто даже не замечая разницы. Резервное копирование настраиваем сразу через штатный pg_dump плюс наш Veeam, чтобы бэкапы шли и на уровне СУБД, и на уровне виртуальной машины.

Отдельно проговариваю с клиентом регламентные операции — на постгресе это автовакуум и переиндексация, они настраиваются иначе, чем на MS SQL, и если их забыть, база через полгода начинает пухнуть и тормозить. У нас в компании это прописано в чеклисте обслуживания сервера, и мы делаем это в рамках абонентки, но если клиент обслуживается сам — обязательно предупреждаю.

Мой практический чеклист перед принятием решения

Прежде чем советовать клиенту переезд, я прохожу несколько простых вопросов. Куплена ли уже лицензия MS SQL и оплачена ли Software Assurance — если да, острой необходимости нет. Растёт ли база быстрее пяти-семи гигабайт в месяц и сколько человек будет работать одновременно через год — если прогноз выше 30-40 пользователей, я склоняюсь к MS SQL. Есть ли доработки, завязанные на специфику MS SQL, и кто их писал — если это давние внешние обработки без документации, риск выше, чем экономия.

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

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

Можно ли поставить обычный PostgreSQL с сайта postgresql.org, а не платную сборку от 1С?
Технически можно, но платформа 1С официально поддерживает только сертифицированную сборку 1С:Предприятие для PostgreSQL — это форк PostgresPro с патчами именно под 1С. На чистом ванильном постгресе база тоже запустится, но при первой же проблеме в техподдержке 1С вам просто откажут, сославшись на несертифицированную СУБД. Мы всегда ставим сборку от 1С — благо она тоже бесплатная, платится только подписка на обновления.

Не станет ли 1С работать медленнее после переезда на PostgreSQL?
На типовых небольших базах — Бухгалтерия, ЗУП, УНФ до 30-50 гигабайт — разницы в скорости пользователи обычно не замечают, а иногда база даже ускоряется, потому что заодно проводится чистка индексов. На больших и сильно доработанных базах с тяжёлыми отчётами возможна просадка на отдельных операциях, и это нужно проверять на тестовом стенде до переезда, а не после.

Нужна ли отдельная лицензия 1С:Предприятие для работы с PostgreSQL?
Нет, лицензии на платформу 1С и клиентские лицензии остаются те же самые, что и для MS SQL. Меняется только СУБД снизу, конфигурация и интерфейс для пользователя выглядят абсолютно одинаково. Экономия именно на серверной части — лицензии MS SQL и её CAL.

Можно ли вернуться на MS SQL, если после переезда что-то пойдёт не так?
Да, откат возможен точно так же через выгрузку и загрузку dt-файла, база 1С не привязывается намертво к конкретной СУБД. Но если вы уже отказались от лицензии MS SQL, для отката её придётся покупать заново — поэтому мы всегда советуем какое-то время держать старый сервер в холодном резерве, хотя бы пару месяцев, пока не убедитесь, что всё работает стабильно.