Managed-база против своей на VPS: за что именно доплата

MAATRIX

Когда в счёте на managed-PostgreSQL или managed-MySQL всплывает цифра в два-три раза выше стоимости VPS с тем же объёмом CPU и RAM, первая реакция — «нас разводят на подписке». Отчасти это справедливо: часть наценки действительно идёт на маркетинг и маржу провайдера. Но за ней стоит и реальный набор работ, которые кто-то делает вместо вас — вопрос в том, нужны ли эти работы именно вашей команде и есть ли у неё время и навыки делать их самостоятельно. Разберём managed-базу по кусочкам: за что конкретно вы платите, что это стоит в виде вашего собственного времени на VPS, и кому доплата действительно окупается, а кому — нет.

Что вообще входит в слово managed

Managed database as a service — это не просто «СУБД, которую кто-то поставил за вас». Под капотом обычно скрывается пять-шесть отдельных сервисов, каждый из которых при самостоятельном администрировании на VPS вам придётся либо настраивать своими руками, либо не делать вовсе (и потом расплачиваться за это в момент инцидента):

• Автоматизированные бэкапы — полные и инкрементальные, с ротацией, хранением в отдельном от базы месте и проверкой восстановимости.
• Патчинг и обновления СУБД — минорные версии накатываются без вашего участия, обычно в окно обслуживания с минимальным даунтаймом или вовсе без него.
• Готовая репликация и отказоустойчивость — реплики для чтения, автоматический failover при падении мастера, синхронизация без ручной настройки.
• Мониторинг из коробки — метрики нагрузки, медленные запросы, алерты на диск/память/подключения, обычно с готовым дашбордом.
• Поддержка провайдера — экспертиза конкретно по этой СУБД, к которой можно обратиться при странном поведении базы, а не только по инфраструктуре в целом.
• Изоляция и безопасность по умолчанию — база не торчит в интернет без пароля, сетевые правила и шифрование соединений настроены заранее.

Ни один из этих пунктов не бесплатен — просто при аренде managed-инстанса их стоимость зашита в тариф, а не выставлена отдельной строкой. При самостоятельном администрировании на VPS вы платите за них не деньгами, а временем: своим или временем специалиста, которого нужно держать в штате или на подряде.

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

Самая понятная часть наценки — бэкапы. Managed-провайдер обычно даёт: ежедневные полные копии, WAL-архивирование для point-in-time recovery, хранение в отдельном от инстанса объектном хранилище, автоматическую ротацию по политике хранения и (у более серьёзных провайдеров) периодическую проверку, что бэкап реально восстанавливается, а не просто лежит битым файлом.

На своём VPS то же самое собирается вручную. Для PostgreSQL это обычно связка pg_basebackup или pgBackRest/WAL-G плюс cron, для MySQL — mysqldump с --single-transaction для InnoDB без блокировки таблиц или Percona XtraBackup для физических копий без остановки сервиса:

# Логический бэкап PostgreSQL с сжатием
pg_dump -Fc -Z 5 -U dbuser -h localhost mydb > /backup/mydb_$(date +%F).dump

# Физический бэкап без остановки сервера (pgBackRest)
pgbackrest --stanza=main --type=incr backup

Ключевая мысль: сам скрипт написать несложно. Сложно — сделать так, чтобы он не тихо ломался месяцами. На своей инфраструктуре нужно отдельно решить: куда складывать копии (не на тот же диск, что и база — иначе это не бэкап, а иллюзия), как проверять восстановимость (регулярный тестовый рестор, а не «наверное, работает»), и как алертить, если задание бэкапа упало. Managed-провайдер эти три вопроса уже закрыл за вас архитектурно — вы просто получаете рабочий бэкап, не думая о его внутренней механике. Подробный разбор самостоятельной настройки — в статье про резервное копирование БД на VPS.

Патчинг и обновления без даунтайма

Второй компонент наценки — обновления. У managed-СУБД минорные версии (там, где чинят уязвимости и баги, но не меняют поведение) накатываются автоматически, обычно ночью в заранее объявленное окно, с graceful restart и минимальным влиянием на доступность. Мажорные версии (например, переход с PostgreSQL 16 на 17) обычно требуют вашего явного согласия, потому что там уже возможны изменения поведения — но сам механизм обновления, включая проверку совместимости, провайдер готовит заранее.

На своём VPS обновление СУБД — это отдельная процедура, которую нужно продумать самостоятельно: проверить changelog на breaking changes, обновить пакет через apt/yum, перезапустить сервис, убедиться, что приложение не упало из-за изменившегося поведения драйвера или расширения. Для минорных патчей это относительно быстро:

sudo apt update && sudo apt install --only-upgrade postgresql-16
sudo systemctl restart postgresql

Но здесь скрыта реальная стоимость — не в команде, а в дисциплине. Managed-провайдер обновляет базу, даже если вы забыли об этом на полгода. Самостоятельно администрируемая база остаётся на дырявой версии ровно до тех пор, пока кто-то не вспомнит проверить apt list --upgradable. Именно отложенный патчинг безопасности — одна из самых частых причин компрометации баз данных, которые годами стоят на VPS без присмотра.

Репликация и отказоустойчивость из коробки

Готовая репликация — third компонент, где разница между managed и своим наиболее ощутима на практике. У managed-инстанса вы обычно получаете реплику для чтения одной кнопкой, а при отказе мастера — автоматический failover: система сама промоутит реплику и переключает подключения, часто без вмешательства человека и в пределах десятков секунд.

Настройка потоковой репликации PostgreSQL на своём VPS — задача решаемая, но многоступенчатая: настроить wal_level = replica на мастере, создать роль для репликации, поднять реплику через pg_basebackup, прописать primary_conninfo, а затем отдельно решить вопрос автоматического failover — вручную PostgreSQL его не делает, нужен внешний инструмент вроде Patroni или repmgr:

# На мастере: роль для репликации
CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'секрет';

# На реплике: клонирование мастера
pg_basebackup -h master_ip -D /var/lib/postgresql/16/main -U replicator -P -R

Сама репликация настраивается за полчаса-час, если делать это не в первый раз. Но именно автоматический failover — то, что вы получаете бесплатно с managed-тарифом — на VPS требует отдельного слоя оркестрации, тестирования сценариев split-brain и понимания, что происходит с приложением в момент переключения. Это не разовая настройка, а постоянная эксплуатационная ответственность. Пошаговая инструкция — в статье про настройку репликации PostgreSQL на VPS.

Мониторинг и экспертная поддержка

Managed-провайдер обычно даёт готовый дашборд с ключевыми метриками: загрузка CPU и диска, число активных подключений, медленные запросы, использование памяти буферным пулом. Это готовая observability без отдельной настройки Prometheus, Grafana и exporter'ов.

На своём VPS то же самое собирается вручную — например, через postgres_exporter и Grafana, с настройкой алертов под конкретную нагрузку:

# docker-compose фрагмент для postgres_exporter
services:
  postgres_exporter:
    image: prometheuscommunity/postgres-exporter
    environment:
      DATA_SOURCE_NAME: "postgresql://monitor_user:пароль@db_host:5432/mydb?sslmode=disable"
    ports:
      - "9187:9187"

Работы на день-два для того, кто уже это делал; на неделю с чтением документации — для того, кто впервые настраивает Prometheus stack. Подробный разбор — в статье про мониторинг баз данных через Grafana.

Отдельная и менее осязаемая часть наценки — экспертная поддержка. У managed-провайдера саппорт обычно понимает внутреннюю механику конкретной СУБД: почему растёт WAL, почему тормозит конкретный тип запроса, что означает та или иная ошибка блокировки. При самостоятельном администрировании эта экспертиза либо у вас в команде уже есть, либо её приходится нарабатывать по ходу дела — читая документацию и логи в момент, когда база уже легла.

Сравнение по цифрам: во что превращается доплата

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

Ориентировочно: managed-тариф с тем же объёмом ресурсов, что и обычный VPS, стоит заметно дороже — но это не «переплата за воздух», а плата за то, что перечисленные выше пять пунктов кто-то уже сделал за вас и продолжает делать на постоянной основе. Вопрос в том, сколько стоило бы вашей команде сделать это самой — в часах работы инженера, а не только в рублях за тариф.

Кому доплата оправдана, а кому нет

Managed-наценка окупается там, где время и внимание команды — более дефицитный ресурс, чем деньги за инфраструктуру:

Доплата обоснована, если:

• в команде нет выделенного DBA или инженера, готового регулярно (а не «когда вспомнит») заниматься бэкапами, патчами и мониторингом;
• простой базы стоит дороже разницы в тарифе — например, это продакшн-БД под платящих пользователей;
• команда небольшая, и время инженера ценнее потратить на продукт, а не на администрирование СУБД;
• нужна отказоустойчивость с автоматическим failover, а строить и тестировать её самостоятельно — не приоритет прямо сейчас.

Доплата, вероятно, избыточна, если:

• в команде уже есть навыки и время самостоятельно администрировать PostgreSQL или MySQL на VPS — тогда managed-наценка оплачивает работы, которые вы и так умеете и готовы делать сами;
• это тестовое окружение, staging или проект на раннем этапе, где downtime в несколько часов не критичен;
• бюджет ограничен сильнее, чем время — разница в цене за год может окупить зарплату части инженерного времени;
• нагрузка предсказуема и невысока, а требования к отказоустойчивости — не строже «восстановиться из бэкапа за час».

Промежуточный вариант тоже существует: держать саму СУБД на своём VPS, но купить managed-объектное хранилище только под бэкапы, или наоборот — взять managed-базу только для продакшна, а тестовые окружения поднимать самостоятельно. Managed и self-hosted — не обязательно выбор «всё или ничего» для всей инфраструктуры компании, это выбор для конкретной базы под конкретную задачу. Если сомневаетесь, с чего начать сравнение подходов шире — не только для БД, но и для VPS в целом — полезно посмотреть на разбор управляемого VPS против неуправляемого: логика наценки там во многом та же самая.

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