В 2026 году сравнение managed PostgreSQL и self-hosted перестало быть вопросом «что дешевле». Чаще это вопрос ответственности: кто отвечает за простой, потерю данных, безопасность и скорость восстановления, и сколько времени команды будет уходить на эксплуатацию базы вместо продукта.
Ниже — разбор для админов/DevOps/вебмастеров: PostgreSQL на VDS против управляемого сервиса, с фокусом на TCO, high availability, бэкапы и PITR, апгрейды, мониторинг, SLA, расширения и тюнинг.
Быстрый ориентир: когда что выбирать
Чтобы не утонуть в деталях, начнём с «карты решений». Она не заменяет расчётов, но быстро показывает типичный перекос в ту или иную сторону.
Managed PostgreSQL чаще выигрывает, если
- нужен понятный SLA и заранее определённая зона ответственности провайдера за платформенную часть;
- нет выделенного DBA/дежурного SRE, а база критична для бизнеса;
- важны штатные бэкапы и PITR «из коробки», без самописных скриптов и регламентов «на бумаге»;
- вы хотите не пропускать security/bugfix обновления (minor upgrades) и уменьшить операционные риски;
- нужна HA без самостоятельной сборки Patroni/keepalived/роутинга и регулярных учений.
Self-hosted PostgreSQL на VDS чаще выигрывает, если
- нужен полный контроль над ОС, сетью, версией PostgreSQL, конфигом и политиками доступа;
- критично иметь доступ к файловой системе и гибко строить бэкапы/архивацию WAL под свои требования;
- есть компетенции и время на эксплуатацию, тесты восстановления и апгрейды без «надежды на авось»;
- нужны «особые» расширения/настройки, которые managed может не разрешать;
- есть внутренние регламенты по размещению, изоляции и контролю ключей.
Главная ловушка self-hosted в том, что стоимость VDS видна сразу, а стоимость ошибок, дежурств и недописанных регламентов проявляется только на инцидентах. В managed наоборот: счёт заметен ежемесячно, а выигрыш в операционке раскрывается при росте нагрузки и требований к надёжности.
TCO в 2026: как считать правильно (а не по цене VM)
TCO (total cost of ownership) в базах данных — это не только CPU/RAM и цена дисков. Это стоимость надёжности: регламенты, тестирование восстановления, мониторинг, обновления, расследование инцидентов, безопасность, документация и дежурства.
Для честного сравнения разложите расходы по слоям и попробуйте оценить их в человеко-часах и потерях от риска.
1) Прямая стоимость платформы
В self-hosted обычно платят за VDS, диски/сеть, иногда отдельные узлы под реплики/кворум, а также за хранилище бэкапов и трафик. В managed часто включены базовые бэкапы и репликация, но важно смотреть ограничения: объём, ретенцию, стоимость хранения WAL, частоту снапшотов, межзональный трафик.
2) Стоимость эксплуатации (самая недооценённая)
Сюда обычно входят:
- настройка и поддержка мониторинга (метрики, алерты, дашборды, синтетические проверки);
- патч-менеджмент ОС и PostgreSQL (minor upgrades);
- процедуры восстановления (бэкапы, PITR, DR-репетиции);
- регулярные проверки: бэкап «не равен» восстановлению, пока вы не прогнали restore-тест;
- performance troubleshooting: autovacuum, bloat, индексы, I/O, блокировки, пул соединений.
В managed часть работ берёт на себя провайдер, но не всё: оптимизация запросов, схемы и индексов почти всегда остаётся на вашей стороне.
3) Стоимость риска и простоя
Если час простоя приложения стоит ощутимых денег, TCO быстро «уходит» в надёжность. При self-hosted вы можете сделать HA, но цена ошибки в архитектуре и автоматизации нередко выше, чем разница в тарифах. В managed вы покупаете не только ресурсы, а зрелые процессы вокруг базы: дежурства, runbook’и, типовой failover, управляемые бэкапы и формализованный SLA.
Практика: выпишите для своей базы RPO/RTO и оцените, сколько стоит достигнуть этих значений в self-hosted с регулярными тестами. Это и будет ваша «скрытая часть» TCO.
Если вы планируете держать PostgreSQL под своим контролем, закладывайте в проект ресурсы на отдельные узлы под реплику(и), бэкап-хранилище и тестовый стенд для восстановления. Удобнее всего это считать от тарифа VDS, а не от «минимальной VM».
High Availability: что на практике означает «HA»
High availability в PostgreSQL — это не «есть реплика». Это предсказуемое переключение при сбоях, защита от split-brain, понятные RPO/RTO, и главное — регулярное тестирование сценариев отказа.
Managed: сильные и слабые стороны HA
Чаще всего managed даёт схему «primary + standby» (иногда несколько реплик) и автоматический failover. Плюсы: меньше ручных действий, меньше шансов забыть про кворум/таймауты. Минусы: вы не всегда контролируете, как устроен failover и какие есть ограничения (поведение при деградации сети, задержка репликации, переключение endpoint/DNS, доступность read-only реплик).
Self-hosted на VDS: из чего реально состоит HA-стек
Зрелая сборка HA на VDS — это обычно не «поднял реплику и готово», а набор компонентов и регламентов:
- оркестрация (часто Patroni) и распределённое хранилище состояния/консенсус;
- роутинг/балансировка, чтобы приложение всегда попадало на текущий primary;
- streaming replication, слоты репликации, контроль lag и защита от переполнения диска WAL;
- fencing/ограничения на failover, чтобы два primary не жили параллельно;
- наблюдаемость: алерты на lag, скорость генерации WAL, состояние репликации, чекпойнты, bloat, блокировки.
Технически это реализуемо, но честный вопрос к себе: готовы ли вы поддерживать стек годами, обновлять компоненты и регулярно проводить «учения» (game day)?
Backups и PITR: где чаще ошибаются
Бэкапы и point-in-time recovery кажутся простыми словами, но именно здесь происходят самые болезненные инциденты. Бэкап, который нельзя восстановить в нужную точку времени в пределах RTO, — это просто архив.
Managed: что обычно удобно и что надо проверить
В managed часто есть встроенные снапшоты и WAL-архивация, а PITR делается через консоль или API. Провайдер обычно решает хранение, ротацию и часть автоматизации восстановления.
Перед выбором уточните заранее:
- глубину ретенции (сколько дней доступен PITR);
- реальную скорость восстановления на больших объёмах данных (и как она зависит от IOPS/CPU тарифа);
- что считается «бэкапом»: снапшот диска, физический бэкап, логический дамп;
- как тарифицируется рост WAL при всплесках записи и какие есть лимиты.
Self-hosted: базовый «боевой» стандарт
Для VDS типичный минимум — физический бэкап с WAL-архивацией (для PITR) плюс периодические логические дампы для выборочных восстановлений и миграций. Бэкапы должны жить отдельно от хоста с базой: отдельный storage/узел/объектное хранилище, контроль доступа, шифрование, ротация.
Если хотите углубиться в практику PITR и типовые ошибки с WAL, полезно держать под рукой отдельный разбор: PITR в PostgreSQL: WAL, бэкапы и восстановление.
Проверка PITR: короткий чек-лист
- Вы знаете свой целевой RPO/RTO и проверяли восстановление на «похожем» объёме данных?
- Вы регулярно поднимаете тестовый стенд из последнего бэкапа и прогоняете базовые проверки приложения?
- У вас есть план на случай повреждения WAL-цепочки или резкого роста объёма WAL?
- Вы понимаете, как влияют на PITR
wal_level, слоты репликации и длительные транзакции?
Минимальный пример команды для логического дампа (не вместо PITR)
Логический дамп не заменяет физические бэкапы с WAL для PITR, но полезен как дополнительная страховка и для выборочных восстановлений.
pg_dump -Fc -d appdb -f /backups/appdb_$(date +%F).dumpЕсли у проекта есть публичные кабинеты, админки или API, обычно параллельно с базой встаёт вопрос TLS и управления сертификатами. В этом случае удобно заранее спланировать выпуск и обновление SSL-сертификатов, чтобы не превращать продление в ручную «пожарную» процедуру.
Апгрейды и безопасность: minor и major без самообмана
Minor version upgrades в PostgreSQL — это исправления ошибок и уязвимостей без изменения формата данных. В self-hosted это ваш процесс: отслеживание релизов, окно обслуживания, обновление пакетов, перезапуск, валидация. В managed это часто автоматизировано и делается по расписанию провайдера.
Практический момент: даже «минорные» апгрейды подразумевают перезапуск. Значит, нужно учитывать поведение пула соединений, таймауты и прогрев кэшей. В managed вы выигрываете в дисциплине обновлений, но можете терять часть контроля над точным таймингом (зависит от настройки maintenance window).
Major upgrade: самая дорогая операция в жизненном цикле
Major upgrade (например, 14→16) — это проект: совместимость расширений, изменения planner/optimizer, потенциально другое поведение запросов, время простоя или миграция «в параллель».
Managed: где проще, а где ограничения
Провайдер может предлагать «кнопку апгрейда» или управляемую миграцию. Это экономит время, но не отменяет тестирования приложения и запросов. Частые ограничения: не все расширения поддерживаются на целевой версии, на время миграции может потребоваться больше диска/IO, а откат иногда сводится к восстановлению из бэкапа.
Self-hosted: рабочие сценарии и дисциплина
Обычно выбор между:
- апгрейдом на месте (быстрее, но сложнее откатывать);
- параллельной миграцией на новый кластер с переключением приложения (дороже по ресурсам, но лучше контроль и откат);
- логической репликацией/миграцией для минимизации простоя (сложнее, важно учитывать DDL, sequence, роли и права).
В любом случае major-upgrade лучше планировать заранее, а не «когда поддержка версии закончилась».
Monitoring и SLA: что вы реально получаете
Monitoring — это не график CPU. Для PostgreSQL критичны: lag репликации, скорость генерации WAL, cache hit ratio, блокировки, autovacuum, bloat, медленные запросы, saturation диска, длительность чекпойнтов.
Managed
Обычно есть базовые дашборды и алерты, иногда интеграции с внешними системами. Проверьте заранее: доступны ли вам сырые метрики и логи, можно ли включить pg_stat_statements, доступен ли auto_explain, и насколько гибко вы настраиваете алерты под свой SLO (а не «как у всех»).
Self-hosted
Вы строите наблюдаемость так глубоко, как нужно, но за это платите временем:
- нужно определить SLO и пороги алертов (чтобы алерт не превращался в шум);
- поддерживать сбор метрик/логов и ретенцию;
- вести runbook’и и практиковать дежурства.
Если база торчит наружу или доступ идёт из разных сетей, не экономьте на базовой гигиене доступа: защита VDS: SSH и firewall.
Extensions и тюнинг: где managed может «не пустить»
PostgreSQL часто используют как платформу, поэтому расширения критичны. В managed список расширений обычно ограничен: часть можно включить, часть — нельзя из соображений безопасности/стабильности/мультиарендности. В self-hosted вы свободнее: ставите расширения из пакетов ОС или собираете из исходников, фиксируете версии под совместимость.
Практический совет: составьте список критичных расширений заранее и проверьте:
- поддержку на целевой версии PostgreSQL;
- политику обновления расширений (кто обновляет и как откатывать);
- нужно ли расширению доступ к ОС/файловой системе (в managed это часто причина запрета).
Performance tuning: контроль против удобства
Self-hosted даёт максимум контроля: параметры памяти, I/O, файловая система, настройки ядра, изоляция соседей, пул соединений. Managed часто ограничивает часть настроек безопасными пресетами, но может давать стабильность и простоту масштабирования.
При этом ключевые зоны тюнинга всё равно почти всегда остаются на стороне команды:
- схема и индексы (покрывающие, частичные, порядок колонок, кардинальности);
- критичные запросы и планы выполнения;
- пул соединений и поведение приложения при ретраях/таймаутах;
- работа autovacuum и контроль bloat;
- архитектура чтений: что уходит на реплики и где допустима eventual consistency.
Чек-лист вопросов перед выбором
- Какие ваши целевые RPO/RTO и как вы будете подтверждать их тестами восстановления?
- Нужен ли PITR и какая глубина ретенции обязательна?
- Какие расширения критичны и как будет происходить их обновление?
- Кто и как делает minor updates, есть ли окно обслуживания?
- Как вы выполняете major upgrade: сценарий, откат, тестирование, сроки?
- Что в SLA считается доступностью: endpoint, успешные транзакции, работоспособность под нагрузкой?
- Какие метрики и логи нужны для расследований, и будут ли они доступны в выбранной модели?
Итог: «managed vs self-hosted» — это про ответственность
Managed PostgreSQL в 2026 — это покупка зрелой операционки вокруг базы (бэкапы/PITR, HA, обновления, часть мониторинга и SLA). Self-hosted PostgreSQL на VDS — это покупка контроля и гибкости, но вместе с ними вы берёте на себя ответственность за процессы, тесты восстановления и качество HA.
Полезная стратегия — не выбирать «раз и навсегда». Нередко self-hosted на VDS оправдан на этапе, когда нужен максимальный контроль и команда готова инвестировать время. Managed становится логичным шагом при росте критичности, когда стоимость простоя и человеческих ошибок начинает доминировать в TCO.
