SQL Server против PostgreSQL считают по полной стоимости

Счет за лицензию редко сам по себе решает судьбу корпоративной базы. Решение становится очевидным, когда прибавка за следующие ядра и резервный узел за три года превышает стоимость миграции, двойной эксплуатации и риска для прикладной системы. До этой точки PostgreSQL может выглядеть бесплатным, но оказаться дорогим проектом. После нее SQL Server Standard может оставаться технически удобным, но финансово незащищаемым.

Я считаю такие варианты не по цене одной СУБД, а по одной и той же рабочей топологии. В смету входят основной и резервный узлы, среда тестирования, люди, поддержка, простой, переделка кода и запас на рост. Если сравнить лицензию SQL Server на мощном сервере с PostgreSQL на одной маленькой виртуальной машине, таблица будет точной и бесполезной.

Цена лицензии растет ступенями вместе с ядрами

SQL Server Standard по модели Per Core покупают пакетами по два ядра, а лицензировать нужно вычислительный ресурс, назначенный экземпляру. Руководство Microsoft по лицензированию указывает минимум четыре лицензии на физический процессор. Для лицензирования отдельной виртуальной машины нужны активная Software Assurance или подписка, поэтому количество vCPU в гипервизоре нельзя автоматически считать окончательным количеством приобретаемых лицензий. Договор, версия продукта и права на виртуализацию должны попасть на проверку поставщику лицензий.

Публичная страница цен SQL Server 2022 дает удобную контрольную цифру: ориентировочная розничная цена SQL Server Standard составляет 3 945 долларов за пакет из двух ядер. Microsoft прямо называет ее ориентиром Open No Level, а не коммерческим предложением. При этой ставке один рабочий экземпляр дает следующую арифметику:

• 8 назначенных ядер: 4 пакета, ориентир 15 780 долларов.
• 16 назначенных ядер: 8 пакетов, ориентир 31 560 долларов.
• 24 назначенных ядра: 12 пакетов, ориентир 47 340 долларов.

Это не итоговая смета в Казахстане: в ней нет курса тенге, налогов, скидки по договору, Software Assurance, Windows Server и резервного узла. Таблица показывает другое. Удвоение ядер удваивает лицензионную строку, даже если база пока использует лишь половину мощности. У PostgreSQL такой ступени нет: PostgreSQL License разрешает использовать, изменять и распространять систему без платы и письменного соглашения.

Сначала зафиксируйте не модель сервера из коммерческого предложения, а ресурс, который реально получит база. Этот запрос дает техническую отправную точку для работающего SQL Server:

SELECT
    cpu_count AS visible_logical_cpu,
    hyperthread_ratio,
    physical_memory_kb / 1024 AS physical_memory_mb
FROM sys.dm_os_sys_info;

SELECT
    name,
    compatibility_level,
    recovery_model_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;

Первая строка результата имеет форму visible_logical_cpu | hyperthread_ratio | physical_memory_mb, затем идет список пользовательских баз. DMV показывает видимый экземпляру ресурс, но не толкует лицензионный договор. Сопоставьте результат с конфигурацией VM, количеством физических процессоров, договором и правами на пассивный узел.

Server + CAL выгоден только при счетных пользователях

Модель Server + CAL может стоить меньше Per Core, если число пользователей или устройств мало, стабильно и доказуемо. На той же публичной странице Microsoft ориентир для серверной лицензии Standard равен 989 долларам, а для одной CAL - 230 долларам. Простейшая граница считается так:

PerCore = ceil(licensed_cores / 2) * price_2core_pack
ServerCAL = server_count * price_server + cal_count * price_cal
break_even_cal = floor((PerCore - server_count * price_server) / price_cal)

Для одного восьмиядерного сервера по этим ориентирам Per Core стоит 15 780 долларов. Server + CAL остается дешевле примерно до 64 CAL, а следующая CAL переводит его через эту границу. Для 16 ядер расчетная граница поднимается примерно до 132 CAL. Эти числа служат проверкой порядка величины, а не предложением к покупке.

Главная ловушка здесь не математика, а определение доступа. Документ Microsoft Multiplexing Licensing Guidance говорит, что пул соединений, веб-приложение или промежуточный сервис не сокращают число нужных CAL. Пользователь, который читает или меняет данные SQL Server через бизнес-приложение, может считаться косвенно обращающимся к серверу. Не берите количество учетных записей базы или одновременно открытых соединений: собирайте пользователей и устройства, которые получают данные автоматическим путем.

Server + CAL разумен для закрытой системы с известными сотрудниками, например для внутреннего приложения на нескольких рабочих местах. Публичный портал, мобильное приложение, интеграционная шина и растущий парк терминалов делают учет хрупким. В такой среде Per Core дороже на старте, зато снимает риск пересчета доступа. PostgreSQL вообще убирает этот вид лицензионного учета.

У PostgreSQL нет лицензионного счета, но есть эксплуатация

Нулевая цена лицензии PostgreSQL не означает нулевую стоимость базы. Текст PostgreSQL License разрешает бесплатное использование, но одновременно отказывается от обязательств по сопровождению, обновлениям и исправлениям. Это честная граница: сообщество выпускает код, а ответственность за рабочий сервис остается у владельца системы или его подрядчика.

В трехлетнюю модель PostgreSQL нужно включить администрирование, резервное копирование с проверкой восстановления, мониторинг, обновления, управление расширениями и дежурство. Те же строки нужны и для SQL Server. Разница состоит в том, какие компетенции уже есть у команды и какие инструменты она успела стандартизировать. Лицензия SQL Server не заменяет эксплуатацию, а бесплатный пакет PostgreSQL не создает ее автоматически.

Считайте сравнимые варианты по формуле:

TCO_36 = licenses
       + infrastructure
       + vendor_support
       + internal_labor
       + migration_project
       + parallel_run
       + expected_downtime_loss
       + training
       + exit_cost

expected_downtime_loss лучше считать как вероятность существенного сбоя, умноженную на согласованную стоимость его последствия, а не как страшную круглую сумму. exit_cost включает выгрузку данных, перенос автоматизации и прекращение поддержки. Если одна сторона получила резервный узел и круглосуточное дежурство, вторая должна получить сопоставимый уровень сервиса.

Для новой системы PostgreSQL часто выигрывает сразу: нет старого T-SQL, миграционного окна и параллельной эксплуатации. Для действующей системы сумма migration_project + parallel_run способна несколько лет перекрывать экономию лицензий. Поэтому срок расчета должен совпадать с горизонтом обновления оборудования, обычно это три или пять лет, а не один бюджетный год.

Сделайте расчет по годам, потому что разовая покупка и постоянные расходы ведут себя по-разному. В нулевом году у SQL Server стоят лицензии и внедрение, у PostgreSQL стоят миграция, обучение и параллельный контур. В следующих годах обе стороны несут расходы на людей, поддержку и инфраструктуру, а SQL Server может потребовать новые лицензии при добавлении вычислительного ресурса. Старые уже оплаченные лицензии отмечайте как невозвратные расходы: они важны для бюджета денежных средств, но не должны искусственно делать будущий вариант дешевле.

Порог окупаемости миграции равен сумме проекта и параллельной эксплуатации, разделенной на подтвержденную годовую разницу расходов. Если проект оценивается в M тенге, параллельный период в P тенге, а ежегодная экономия после перехода в S тенге, срок равен (M + P) / S. При отрицательном или близком к нулю S миграция не окупается за счет СУБД. Тогда ее можно обосновать только другой пользой приложения, которую следует оценить отдельно.

Сделайте чувствительность по четырем величинам: курсу валют для лицензий, росту ядер, ставке команды и объему ручной переделки. Не меняйте все допущения одновременно. Так видно, что именно переворачивает решение. Например, если PostgreSQL выигрывает при любом курсе, но проигрывает после удвоения часов конверсии, нужен более глубокий аудит кода. Если SQL Server выигрывает только без резервного узла, спор идет уже не о СУБД, а о заниженном уровне доступности.

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

Совместимость прикладной системы может закончить сравнение

Если поставщик прикладной системы сертифицирует только SQL Server, выбор уже сделан на уровне приложения. Формальная способность PostgreSQL хранить те же таблицы ничего не меняет: неподдерживаемая база может лишить организацию обновлений и превратить каждый инцидент в спор между подрядчиками. Сначала запросите у владельца приложения письменную матрицу поддерживаемых СУБД, версий, драйверов и режимов отказоустойчивости.

Для собственной разработки совместимость распадается на несколько проверок. Обычные таблицы, индексы, ограничения и простые запросы переносятся сравнительно спокойно. Риск растет там, где приложение зависит от T-SQL, SQL Server Agent, Database Mail, CLR, linked servers, табличных параметров, специфичных подсказок оптимизатору, SSIS или отчетов, которые используют особенности Microsoft.

Документация AWS Schema Conversion Tool хорошо показывает масштаб различий, хотя сам инструмент нацелен на сервисы AWS. Она не обещает механический перенос: для SQL Server Agent и Database Mail нужен пакет эмуляции, процедуры иногда преобразуются в функции, одинаковые имена индексов приходится делать уникальными, а отдельные системные функции заменяются совместимыми обертками. Я бы считал каждый такой объект не «процентом конверсии», а будущей зависимостью, которую нужно тестировать и сопровождать.

Перед спором о лицензиях соберите фактические зависимости:

SELECT
    o.type_desc,
    QUOTENAME(SCHEMA_NAME(o.schema_id)) + '.' + QUOTENAME(o.name) AS object_name
FROM sys.objects AS o
JOIN sys.sql_modules AS m ON m.object_id = o.object_id
WHERE m.definition LIKE '%OPENQUERY%'
   OR m.definition LIKE '%MERGE%'
   OR m.definition LIKE '%xp[_]%'
   OR m.definition LIKE '%sp[_]OACreate%'
ORDER BY o.type_desc, object_name;

SELECT name, enabled
FROM msdb.dbo.sysjobs
ORDER BY name;

Пустой результат не доказывает совместимость, зато непустой сразу дает очередь на разбор. Отдельно просканируйте репозитории на T-SQL, строки подключения, ORM-провайдеры и запросы, которые строятся во время работы приложения.

Миграция стоит больше переноса таблиц

Бюджет миграции определяет количество поведения, привязанного к SQL Server, а не размер файлов базы. Терабайт простых таблиц иногда переносится предсказуемее, чем небольшая база с сотнями процедур, заданиями Agent и отчетами. Объем данных в первую очередь влияет на длительность копирования и окно переключения. Объем специфичного кода влияет на месяцы инженерной работы.

Разделите проект на оплачиваемые пакеты работ:

1. Инвентаризация охватывает схемы, код базы, задания, интеграции, отчеты, права, RPO и RTO.
2. Конверсия заменяет типы данных, T-SQL, процедуры, функции и эксплуатационные задания.
3. Перенос данных включает полную загрузку, доставку изменений и сверку строк, сумм и контрольных выборок.
4. Проверка приложения проходит функциональные, нагрузочные, блокировочные и аварийные сценарии.
5. Переключение включает репетицию, заморозку изменений, критерии отмены и возврат на исходную систему.

Не прячьте исправление приложения в строке «миграция БД». Например, различия в регистре имен, работе NULL, сортировках, датах, IDENTITY и последовательностях могут проявиться только в редкой ветке бизнес-процесса. PostgreSQL документирует собственные типы и поведение, но соответствие стандарту SQL не означает взаимозаменяемость с T-SQL.

Цена простоя тоже не равна длительности копирования. При полном переносе окно включает остановку записи, финальную синхронизацию, проверку, запуск приложения и решение продолжать или откатываться. Если бизнес допускает только короткое окно, добавятся захват изменений, повторяемый прогон и более сложный план отката. Покупка этих работ часто разумнее героического ночного переключения без репетиции.

Заложите параллельную эксплуатацию минимум на период, который покрывает закрытие месяца, массовый отчет или другой редкий цикл системы. Именно там всплывают расхождения округления, часовых поясов и планов запросов. Выключать SQL Server сразу после успешного входа пользователей опасно, а продолжать платить за него без даты выхода дорого.

Проверка данных должна доказывать смысл, а не только равенство количества строк. Сверьте число объектов и строк, суммы по денежным полям, минимальные и максимальные даты, долю NULL, уникальность бизнес-ключей и выборочные документы целиком. Для больших таблиц разбейте сверку по диапазонам первичного ключа или дате, чтобы ошибка не растворилась в общем итоге. Отдельно проверьте строки с кириллицей, пробелами, пустыми значениями, старой кодировкой и датами на границе часового пояса.

Запишите, какая система остается источником истины на каждом этапе. Двусторонняя запись кажется удобным способом снизить риск, но быстро создает конфликтующие последовательности, разные моменты фиксации и трудный откат. Без доказанной необходимости безопаснее держать запись в SQL Server, переносить изменения в PostgreSQL, проверять чтение, затем провести одно управляемое переключение. Если нужна обратная синхронизация, проектируйте ее как отдельную функцию с правилами разрешения конфликтов.

Критерий отката должен быть измеримым: потеря подтвержденных транзакций, превышение p95, ошибка контрольного отчета или невозможность завершить бизнес-операцию за установленное время. Фраза «если что-то пойдет не так» оставляет решение уставшему руководителю посреди ночи. Назначьте человека, который объявляет откат, и последний момент, когда возврат еще помещается в окно.

Специалисты меняют экономику после запуска

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

Для рынка Казахстана соберите данные самостоятельно в течение одной недели, потому что вакансии и ставки меняются быстрее срока жизни статьи. Отправьте одинаковое описание дежурства трем местным подрядчикам, посчитайте подходящих внутренних сотрудников и проверьте срок замены человека. В запросе должны быть версия СУБД, объем, число узлов, график поддержки, RPO, RTO, резервное копирование и ожидаемая частота релизов.

Сравнивайте четыре числа: месячную стоимость основной команды, стоимость дежурства, цену разового сложного вмешательства и время найма замены. Высокая ставка опытного PostgreSQL DBA может оставаться выгоднее ежегодной лицензионной нагрузки. Дешевый специалист без опыта восстановления способен уничтожить эту экономию одним затяжным простоем. Для SQL Server действует та же логика, хотя существующая команда Microsoft часто уменьшает стоимость перехода между задачами.

Обучение имеет смысл считать как рабочее время, а не как цену курса. После курса команда еще пишет инструкции, проводит учебное восстановление и проходит первые обновления с проверкой. Пока второй человек не может восстановить сервис без автора конфигурации, организация зависит от одного сотрудника, и это финансовый риск.

Отказоустойчивость надо считать в одинаковой топологии

Основной узел без резерва нельзя сравнивать с парой узлов. У SQL Server Standard базовая группа доступности поддерживает одну базу, одну вторичную реплику, не дает читать вторичную реплику и выполнять на ней резервное копирование. Это ограничения, перечисленные Microsoft Learn. Если приложению нужно согласованно переключать несколько баз или разгружать чтение на реплику, Standard может потребовать другую архитектуру либо переход к более дорогой редакции.

PostgreSQL поддерживает физическую потоковую и логическую репликацию, но из этого не возникает готовый кластер. Нужно выбрать механизм переключения, хранение кворума, маршрутизацию подключений, архив WAL, наблюдение за отставанием и процедуру возврата бывшего основного узла. Расширения и менеджеры кластера тоже получают версии, владельцев и инструкции обновления.

Лицензирование резервного SQL Server зависит от приобретенных прав, Software Assurance, роли узла и сценария использования. Не закрепляйте в модели предположение «пассивный узел всегда бесплатен». Перед покупкой нарисуйте схему с каждым физическим сервером, VM, контейнером и направлением доступа, затем получите письменный расчет поставщика по этой схеме.

Одинаковый приемочный тест для обеих СУБД полезнее списка функций. Отключите основной узел в испытательной среде, измерьте потерю подтвержденных транзакций, время восстановления записи и действия оператора. Потом восстановите базу из резервной копии на отдельный хост. Если команда не может показать оба результата, заявленный RPO или RTO пока существует только в документе.

Производительность не равна числу лицензируемых ядер

Больше ядер не гарантирует пропорционально более быстрый SQL Server, зато по модели Per Core почти наверняка увеличивает лицензионную основу. До закупки измерьте, упирается ли система в процессор, память, хранилище, блокировки или плохие планы запросов. Покупка еще восьми ядер для базы, которая ждет диск или удерживаемую транзакцию, делает лицензию дороже и оставляет задержку на месте.

Снимите профиль минимум за обычный день, закрытие периода и пиковую операцию. Нужны загрузка процессора, время ожиданий, чтения и записи, задержка хранилища, объем активного набора данных, рост журнала, длительные запросы и блокировки. Для виртуальной машины добавьте готовность процессора со стороны гипервизора и фактические ограничения памяти. Средняя загрузка за месяц скрывает короткий пик, ради которого бизнес и просит новое оборудование.

Уменьшение назначенных vCPU иногда дает двойную экономию: снижает стоимость SQL Server и заставляет команду исправить дорогие запросы. Но уменьшать ресурс до теста нельзя. Проверьте пиковую нагрузку на копии приложения, сохраните p95 и p99 времени ответа, пропускную способность и запас до насыщения. Лицензионная оптимизация, после которой очередь растет без ограничения, обойдется дороже дополнительных пакетов ядер.

PostgreSQL снимает лицензионный штраф за ядро, но физику нагрузки не меняет. Ему тоже нужны память, подходящие индексы, обслуживание статистики, контроль разрастания таблиц и хранилище с предсказуемой задержкой. Планировщики двух СУБД выбирают разные планы на одних данных, поэтому перенос результатов теста SQL Server на PostgreSQL по коэффициенту не работает. Выполните один и тот же набор бизнес-операций и сравните предел системы, а не один красивый запрос.

Разделяйте вертикальный рост и горизонтальное разнесение. Отчеты, интеграции и архивные операции можно вынести из основного контура, если приложение и требования к актуальности это допускают. Для SQL Server такое решение может уменьшить число дорогих ядер основного экземпляра, но новый экземпляр тоже требует проверки лицензий. Для PostgreSQL дополнительные узлы не создают плату за ядра, зато прибавляют репликацию, наблюдение и аварийные процедуры.

Аппаратная смета должна фиксировать не бренд процессора, а число назначенных ядер, частоту, память, тип и задержку хранилища, сетевые пути и запас емкости. Тогда два предложения можно нагрузить одинаковым профилем. Иначе поставщик SQL Server предложит меньше быстрых ядер ради лицензии, поставщик PostgreSQL больше средних ядер без платы, а комиссия будет сравнивать несопоставимые серверы.

Пилот превращает спор в смету

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

До запуска запишите критерии приемки в одной таблице:

• Конверсия схемы: число объектов ручной правки, согласованный максимум, цена в человеко-днях, владелец архитектор БД.
• Пиковая нагрузка: p95 времени ответа, SLA приложения, цена в человеко-днях и оборудовании, владелец команда приложения.
• Перенос изменений: отставание от источника, порог меньше окна переключения, цена в человеко-днях, владелец DBA.
• Восстановление: фактические RPO и RTO, договорные значения, цена инфраструктуры и дежурства, владелец эксплуатация.
• Откат: время возврата на SQL Server, предел окна, цена в человеко-днях, владелец переключения.

После пилота замените проценты конверсии списком объектов и оценкой часов. Добавьте 20-30 процентов к незнакомым классам работ как резерв оценки, но не ко всей смете автоматически. Если подрядчик не может объяснить, какой риск покрывает резерв, это просто спрятанная маржа.

Пилот PostgreSQL стоит прекратить, если прикладной поставщик не поддерживает результат, критическая функция требует постоянной эмуляции или окно переноса не проходит после двух осмысленных попыток. Пилот SQL Server стоит пересчитать, если рост ядер, резервная площадка или CAL выводят трехлетний бюджет за установленный предел. Остановка плохого варианта экономит больше, чем доведение красивой демонстрации до промышленной аварии.

Решение меняется по типу нагрузки

Для новой собственной системы без жесткой зависимости от T-SQL PostgreSQL обычно дает более чистую экономику. Команда сразу пишет переносимый SQL, строит эксплуатацию под выбранную СУБД и не оплачивает параллельную работу двух платформ. Сэкономленный лицензионный бюджет лучше направить на резервирование, наблюдаемость и второго подготовленного администратора.

Для купленной учетной, медицинской или отраслевой системы с сертификацией только под SQL Server Standard миграция ради лицензии часто ошибочна. Цена неподдерживаемого приложения выше, чем экономия на СУБД. Здесь стоит оптимизировать число лицензируемых ядер, изоляцию нагрузки, модель CAL и жизненный цикл сервера, не меняя поддерживаемую основу.

Для внутренней системы с небольшим фиксированным кругом сотрудников проверьте Server + CAL. Для портала или множества косвенных пользователей чаще проще Per Core либо PostgreSQL, потому что учет CAL становится отдельным процессом контроля. Для аналитики с ростом ядер пересчет проводят особенно рано: лицензионная линия SQL Server увеличивается вместе с вычислительным ресурсом, а перенос большого числа специфичных процедур дорожает вместе с задержкой решения.

Системный интегратор нужен не для выбора любимой СУБД, а для одной ведомости допущений. GSE.kz может сопоставить серверную топологию, программное обеспечение, интеграцию и поддержку в едином проекте, сохранив нейтральность к поставщику. В такой ведомости отдельно видны лицензии, оборудование, миграционные работы и эксплуатация, поэтому скидка на одну строку не маскирует рост другой.

Деньги становятся решающими после учета выхода

Финансовая граница выражается простой проверкой: накопленная разница ежегодных расходов должна окупить миграцию, параллельную работу и риск до следующего планового обновления. Рассчитайте ее для базового роста, медленного роста и пикового сценария. Если PostgreSQL окупается только при идеальной миграции и максимальном росте ядер, решение хрупкое. Если он окупает консервативную оценку миграции за приемлемый срок, лицензионная разница уже решающая.

SQL Server Standard стоит оставить, когда поддержка приложения обязательна, существующая команда сильна, а лицензируемые ядра и CAL предсказуемы. PostgreSQL стоит выбирать, когда приложение допускает перенос, рост вычислений заметен, команда может владеть эксплуатацией, а пилот подтвердил производительность и переключение. Наличие старой лицензии не делает будущие ядра бесплатными, как отсутствие лицензионного счета не делает миграцию безопасной.

Первый рабочий документ должен занимать одну страницу: схема узлов, ядра или CAL, трехлетний TCO, список несовместимостей, цена миграции, RPO, RTO и дата выхода из параллельной эксплуатации. Попросите владельцев финансов, приложения и эксплуатации подписать именно допущения. После этого спор о брендах обычно заканчивается, потому что становится видно, за какой риск организация платит.