Своя база данных или управляемый сервис: считаем реальную стоимость на горизонте трёх лет

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

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

Кто что делает: своя база данных против облака

Самостоятельная установка СУБД не сводится к единоразовому развёртыванию программного пакета. Она предполагает комплекс мероприятий:

• выделение физической или виртуальной инфраструктуры;
• настройку операционной системы;
• конфигурирование сетевых правил;
• организацию пула соединений;
• внедрение системы мониторинга и оповещений;
• регулярное выполнение резервного копирования с обязательной проверкой возможности восстановления данных;
• настройку репликации с автоматическим переключением при отказе (failover);
• проведение плановых минорных обновлений;
• реализацию потенциально рискованных мажорных обновлений;
• ротацию криптографических ключей;
• оперативное реагирование на возникающие инциденты.

Каждая из перечисленных задач требует специализированных знаний и компетенций.

При использовании управляемой базы данных пользователь фокусируется исключительно на бизнес‑задачах: управлении пользователями и ролями, проектировании схемы данных и формировании запросов. Все инфраструктурные и эксплуатационные аспекты берёт на себя провайдер.

Кто реально умеет эксплуатировать базы

У небольшой команды редко есть выделенный администратор баз данных (DBA) — обычно эту роль закрывает «системный администратор по совместительству». Пока система работает штатно, специалист справляется. Но стоит возникнуть серьёзной проблеме — упала репликация, сломался WAL, запустился каскад блокировок, — как он упирается в потолок собственной экспертизы. В таких случаях приходится обращаться в поддержку вендора, искать ответы на форумах или в чужих Slack‑чатах.

У больших команд DBA есть, но и здесь не всё гладко: реакция на серьёзный инцидент обычно оборачивается как минимум выходными для одного специалиста и нервным понедельником для всей команды.

С Yandex Cloud ситуация принципиально иная. Команда платформы данных — это не просто администраторы, а разработчики, которые пишут код PostgreSQL в апстрим. Это кардинально меняет подход к эксплуатации баз данных.

Практическое следствие такой вовлечённости — беспрецедентная скорость обновления. Мажорные версии PostgreSQL в Yandex Cloud появляются практически сразу после релиза апстрима — в тот же день. Уже в день релиза можно развернуть кластер на новой версии, а возможность бесшовного апгрейда со старой версии становится доступна в течение трёх месяцев.

Экспертиза команды воплощается и в собственных опенсорс‑проектах:

• Odyssey — пулер соединений, который используется в Яндексе с 2018 года и с самого начала интегрирован в Yandex Cloud.
• WAL‑G — система резервного копирования, также встроенная в Yandex Managed Service for PostgreSQL и доступная всем желающим через открытый исходный код.
• Yezzey — расширение для Greenplum^®/Cloudberry^®, позволяющее отгружать часть данных с хостов баз данных в Yandex Object Storage и тем самым экономить место на диске.

Оперативность и гибкость подхода Yandex Cloud проявились и в реакции на внешние изменения:

• Когда в 2024 году Redis^® поменял лицензию на проприетарную, сообщество создало форк под BSD — Valkey^™. Мы оперативно, в декабре 2024 года, перевели свой управляемый сервис для Redis на Valkey и стали одним из контрибьюторов проекта.

• После того как Greenplum (MPP‑СУБД на базе PostgreSQL) фактически перестал развиваться после ухода Broadcom, сообщество ответило форком — Apache Cloudberry^® (сейчас находится под инкубацией Apache Software Foundation). В апреле 2026 года Леонид Борчук, разработчик из нашей команды, вошёл в PPMC проекта; другой наш старший разработчик — Николай Антонов, стал контрибьютором в апреле текущего года. С 2026 года в Yandex Cloud доступна сборка Cloudberry с расширениями Yezzey и PXF. Сервис объединил старые версии Greenplum и новые Cloudberry под общим названием Yandex MPP Analytics Engine for PostgreSQL.

• Аналогичным образом мы поступили с Elasticsearch: после изменений в лицензионной политике переключили собственный управляемый сервис и наших клиентов на свободный форк OpenSearch. Наша команда активно участвует в развитии проекта и вносит свой вклад в его кодовую базу.

• Отдельного внимания заслуживает ClickHouse^®. Хотя проект теперь развивается отдельной компанией, мы сохранили глубокую экспертизу и продолжаем двигать технологию вперёд. Например, только в нашем облаке реализована поддержка гибридного хранилища для ClickHouse: часто используемые данные хранятся на сетевых дисках кластера, а редко используемые автоматически перемещаются в Yandex Object Storage — это позволяет оптимизировать затраты без потери производительности.

Итог очевиден: когда у вас под капотом база, разработанная теми же людьми, которые её эксплуатируют, мажорное обновление не растягивается на квартал. Релизы поддерживаются сразу, а сложные кейсы попадают в апстрим как полноценные фиксы, а не временные костыли.

Высокая доступность базы данных без ручной настройки

Чтобы обеспечить минимальную отказоустойчивость в самостоятельной инсталляции PostgreSQL, потребуется развернуть:

• мастер‑сервер (master);
• синхронную реплику;
• асинхронную реплику;
• три экземпляра пулера соединений (pgbouncer или Odyssey).

Кроме того, нужно регулярно проводить проверки failover и учебные отработки, чтобы команда не утратила навыки восстановления кластера в случае реального сбоя.

В Yandex Managed Service for PostgreSQL всё значительно проще: достаточно отметить пару чек‑боксов, например выбрать опцию «3 хоста, по одному в каждой зоне доступности». При недоступности одной из зон мастер‑хост кластера автоматически переключится за считаные секунды.

Дополнительный плюс Yandex Cloud — поддержка сетевых дисков. Благодаря им можно построить высокодоступный кластер всего на двух хостах вместо трёх. В итоге вы сокращаете расходы на инфраструктуру на треть — без потери надёжности.

Бэкапы, на которые можно положиться

Когда говорят «у нас есть бэкапы», зачастую речь идёт лишь о двух вариантах, и у каждого есть существенные ограничения:

• Ночной дамп. В случае серьёзного инцидента вы рискуете потерять до 24 часов данных — всё, что было создано или изменено после последнего бэкапа.
• Обвязка с WAL‑G/pgBackRest. Хотя такой подход теоретически позволяет восстановить базу на произвольную точку во времени (Point‑In‑Time Recovery, PITR), на практике механизм проверяют редко — обычно раз в год во время учений. И зачастую такие проверки выявляют неожиданные проблемы.

В большинстве управляемых сервисов баз данных PITR работает «из коробки» без дополнительных настроек. Представьте ситуацию: джуниор‑специалист случайно удалил критичную таблицу в 12:34. С PITR вы просто поднимаете кластер из бэкапа на этот момент времени — и все транзакции, зафиксированные до 12:34, сохраняются. PITR можно реализовать и при локальной установке базы, но для этого потребуется сначала вручную настроить механизм восстановления, а затем привлечь системного администратора для выполнения процедуры.

Преимущества управляемого сервиса в работе с бэкапами

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

Это особенно важно для финансовых и регуляторных сценариев: во многих случаях требуется хранить данные дольше 6–12 месяцев. При самостоятельной установке пришлось бы вручную выстраивать отдельный пайплайн — загружать архивы в S3, настраивать ротацию и вести инвентаризацию. В управляемом сервисе всё гораздо проще: достаточно выбрать нужные параметры в настройках кластера.

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

Управляемый сервис — это не просто «виртуальная машина с настроенной базой данных»

Грань тонкая, но принципиальная. Если вам предоставляют виртуальную машину, на которой кто‑то уже установил PostgreSQL и подготовил конфигурационный файл, — по сути, это всё ещё ваша виртуальная машина. Вы получаете root‑доступ, а значит, несёте полную ответственность: любые ошибки — ваши, и уровень обслуживания сводится к формуле «как успеете».

Настоящий управляемый сервис устроен иначе. В нём у вас нет root‑доступа к хосту. Нельзя произвольно менять параметры ядра, устанавливать любые расширения или вручную править конфигурационные файлы. Именно эта ограниченность прав — та цена, которую вы «платите» за то, чтобы облако взяло на себя ответственность за стабильную работу базы данных.

При этом вы по‑прежнему можете создавать пользователей и базы данных, выдавать роли и управлять правами доступа, настраивать только те параметры СУБД, которые поддерживает сервис, и работать с расширениями — но лишь из утверждённого списка. Вы сохраняете возможность подключаться через любые клиенты и снимать метрики с помощью стандартного API, а также автоматизировать управление через код — с помощью Terraform, REST, gRPC или CLI.

Облачные СУБД при этом интегрированы с системой авторизации через Yandex IAM. Это избавляет от необходимости хранить пары «логин-пароль» непосредственно в базе: идентичность пользователя проверяется через централизованное управление доступом облака.

Часто недооценивают два момента, пока не случится инцидент. Во‑первых, в Yandex Cloud есть централизованное хранилище реквизитов подключения (Yandex Connection Manager), которое автоматически создаёт подключения для новых кластеров PostgreSQL, MySQL^®, ClickHouse^®, Apache Kafka^®, Trino и других. В нём же можно хранить данные соединений с СУБД, размещёнными вне облака. В результате исчезают проблемы с паролями в application.yml, копиями pg_hba.conf в чатах и постмортемами из‑за утечек данных.

Во‑вторых, доступен механизм Yandex Audit Trails, фиксирующий в логах каждое действие с кластером через API: кто, когда и что изменил, какое было состояние до и после. Логи можно выгружать в S3‑бакет, Yandex Monium или Yandex Monitoring, а затем фильтровать и анализировать с помощью Yandex DataLens. Если же вы используете виртуальную машину, такой мониторинг пришлось бы настраивать отдельно — это полноценный проект, требующий времени и ресурсов. Ваш отдел информационной безопасности точно оценит преимущество готового решения.

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

Метрики и наблюдаемость, которые уже работают

Поднять Prometheus^®, node-exporter, postgres-exporter, Grafana, написать алерты, поддерживать дашборды — занятие не из простых с непонятной сходимостью в будущем. В Yandex Cloud каждый кластер из коробки отдаёт больше сотни метрик в Yandex Monitoring. Благодаря этому доступны готовые дашборды на уровне кластера и каждого хоста. Кроме того, система предоставляет гибкие возможности оповещения: алерты приходят в Telegram, на почту, по СМС и даже в виде звонков. А для интеграции с внешними системами предусмотрен экспорт в Prometheus через стандартный API.

SLA — где он реально лучше

Подробнее посмотреть на цифры можно в соглашении.

Разберём на примере, в чём практический смысл разделения операций чтения и записи: если мастер‑сервер становится недоступен, приложение теряет возможность выполнять операции записи. Но реплики остаются работоспособными — и приложение, которому достаточно режима read‑only, продолжает обрабатывать запросы.

В случае с одиночной виртуальной машиной ситуация принципиально иная: при сбое становится недоступна вся база данных, а значит, приложение полностью выходит из строя.

Считаем расходы

Возьмём типовой продакшен PostgreSQL: три узла в HA-конфигурации, на узел — 16 vCPU, 32 ГБ RAM, ~500 ГБ диска. Горизонт планирования — три года. Цены — в рублях, без корпоративных скидок.

Вариант 1. On-premises

Базовый сервер начального уровня:

• Intel^® Xeon Silver 4314, 16 ядер, 2,4 ГГц
• 32 ГБ DDR4 RDIMM 3200 МГц
• 2 порта 10 Гбит/с SFP+
• SATA SSD 480 ГБ + NVMe SSD 1 ТБ
• Цена с НДС — 648 814 рублей

Три сервера на отказоустойчивый кластер — 1 946 442 рубля капитальных расходов.

Множитель ×2 — консервативная оценка накладных расходов: размещение, питание, охлаждение, сетевая обвязка. Затраты на зарплату DBA — 250 000 руб., а социальные взносы составят 30% от неё. Потребуется два специалиста, каждый из которых администрирует базу 50% времени.

Вариант 2. PostgreSQL на Yandex Compute Cloud вручную

Три виртуальные машины Intel^® Ice Lake, 16 vCPU и 32 ГБ RAM каждая, под Patroni-кластером:

С CVoS на 1 год (зарезервированные ресурсы) счёт за виртуальную машину падает до 77 300 руб/мес., итог — ~402 000 руб/мес.

Вариант 3. Yandex Managed Service for PostgreSQL

Три хоста Intel^® Ice Lake, такая же конфигурация по ресурсам:

С CVoS на год — кластер 102 750 руб/мес., итог — ~135 300 руб/мес.

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

Сводная таблица

Последней строчкой добавим высокодоступный кластер на двух хостах — на сетевых дисках в облаке такая конфигурация возможна. Это даёт ещё минус 33% к стоимости инфраструктуры.

Вывод

Управляемая база дороже по железу примерно на треть и дешевле по совокупной стоимости — на 70–80%. Эту разницу даёт не «магия облака», а вполне конкретные вещи:

• Команду эксплуатации баз данных заменяет команда вендора, которая пишет код этих СУБД в апстрим.
• Отказоустойчивая HA-конфигурация в трёх зонах доступности доступна без отдельного инженерного проекта.
• PITR и расписание бэкапов с хранением до трёх лет работают из коробки, без своих пайплайнов архивирования.
• Метрики, алерты, аудит, ролевая модель — встроенные. Не надо собирать стек наблюдаемости.
• Управление как кодом — Terraform, REST/gRPC API, CLI, IAM — встраивается в любой современный платформенный пайплайн без переделок.

Если у вас Yandex Cloud, но базы всё ещё стоят на собственных виртуальных машинах — пересчитайте TCO на актуальных ценах. Для большинства инсталляций управляемый сервис окупается на горизонте года, а высвобожденное время DBA уходит туда, где оно реально приносит деньги — в продукт, а не в дежурство.