О чём спор: PostgreSQL на VDS против managed database
Если упростить, выбор выглядит так:
PostgreSQL на VDS — вы управляете ОС, дисками, сетью, обновлениями, резервными копиями, репликацией и отказоустойчивостью. Максимум контроля и гибкости, но больше ответственности.
Managed database — провайдер обслуживает PostgreSQL как сервис: бэкапы, мониторинг, автоматические обновления (часто с окнами), иногда high availability и заявленный SLA. Меньше рутины, но больше ограничений.
Ниже сравнение не в стиле «что быстрее», а по тому, что чаще всего болит у админов и DevOps: стоимость владения (TCO), предсказуемость SLA, сценарии high availability, восстановление по времени (PITR), безопасность и границы контроля.
Ключевые критерии выбора: список вопросов перед стартом
Чтобы разговор был предметным, начните с короткого чек-листа. Если хотя бы 2–3 пункта критичны, выбор обычно становится очевиднее.
Нужен ли root-доступ и возможность менять параметры ОС/ядра/ФС под базу?
Есть ли требования по комплаенсу и аудиту: где лежат ключи, кто имеет доступ, как ведутся логи?
Какой целевой RPO/RTO: сколько данных вы готовы потерять и сколько времени допустимо восстанавливаться?
Нужны ли расширения PostgreSQL, кастомные сборки, нестандартные настройки?
Какой профиль нагрузки: короткие транзакции, аналитика, много коннектов, тяжёлые отчёты?
Есть ли команда и процессы, которые реально будут «дежурить» по базе: мониторинг, алерты, on-call, регламенты?
Практическое правило: если нет времени и людей на эксплуатацию, «дешевле» почти всегда оказывается тот вариант, где меньше ручных точек отказа и меньше поводов для ночных инцидентов.
TCO: почему «дороже/дешевле» почти всегда считают неправильно
TCO в контексте PostgreSQL — это не только цена ресурса (VDS или managed database). Рабочая модель включает:
Инфраструктуру: CPU/RAM/диск/сеть, отдельные тома/узлы, место под архивы WAL и базовые бэкапы, часто — реплики.
Операционные затраты: время инженера на обновления, проверку бэкапов, тесты восстановления, реакцию на инциденты.
Цена простоя: стоимость часа недоступности (деньги, репутация, штрафы по вашим договорам).
Цена ошибок: случайно удалили данные, приехала поломанная миграция, переполнился диск, «почистили место» не там, где нужно.
У managed database инфраструктурные и операционные затраты часто «спрятаны» в цене. На своей VDS они явно ваши — но вы можете оптимизировать архитектуру под задачу и не платить за ненужные функции.
Если база — критичный компонент, выигрывает не тот вариант, где ниже чек, а тот, где дешевле обходятся регулярные операции и инциденты.
Когда TCO обычно ниже на VDS
Есть опытная команда и стандарты эксплуатации (IaC, мониторинг, регламенты обновлений).
Нужны нестандартные настройки, расширения, собственные подходы к бэкапам/репликации/сетевому периметру.
Хочется построить архитектуру «ровно под себя» и экономить на абстрактных сервисных надбавках.
Когда TCO обычно ниже у managed database
Нет времени или людей на обслуживание, но нужен предсказуемый результат (бэкапы, PITR, алерты, патчи).
PostgreSQL — не ключевая компетенция, и «держать DBA» нерационально.
Нужно снизить человеческий фактор: забыли включить архивацию WAL, не проверили восстановление, не увидели рост места.
SLA и зона ответственности: что именно вам обещают
Термин SLA звучит одинаково, но означать может разное. Полезно отделять:
Доступность платформы (хост, сеть, диски) — типичная зона ответственности провайдера.
Доступность именно PostgreSQL — зависит от того, кто управляет сервисом и как устроен кластер/фейловер.
Сохранность данных — почти всегда с оговорками: период хранения, корректная конфигурация, исключения по форс-мажорам.
На своей инфраструктуре вы чаще всего получаете SLA на «железо/виртуализацию/канал», а доступность PostgreSQL — это ваша архитектура и эксплуатация. У managed database SLA чаще ближе к прикладному уровню: «инстанс базы доступен», но вы платите за ограничения и правила сервиса.
Если вы выбираете вариант на своей стороне, обычно логично начинать с надёжной базы по инфраструктуре: VDS с понятными характеристиками диска и сети проще укладывать в прогнозируемые RPO/RTO, чем «как повезёт» на случайных ресурсах.
High availability: что скрывается за словами «есть HA»
High availability — это не один флажок. Это набор решений: репликация, автоматический failover, кворум, fencing, контроль split-brain, проверка лагов, обслуживание без простоя.
В managed database HA часто идёт «пакетом»: primary + standby, автоматическое переключение, иногда чтение с реплик. Но детали критичны:
Как быстро происходит failover и что с активными транзакциями?
Какая модель репликации: synchronous или asynchronous?
Как устроены окна обслуживания и что происходит при обновлениях?
Можно ли управлять параметрами репликации/таймаутами и видеть реальные метрики лагов?
На VDS у вас свобода построить HA под себя: от streaming replication до схем с менеджером кластера и виртуальным IP. Но ответственность полностью ваша: мониторинг роли узлов, тесты сценариев, регламенты переключения, защита от split-brain.
Если вы не готовы регулярно репетировать аварийные переключения, «самостоятельный HA» часто превращается в «теоретический HA».
PITR: восстановление «на момент времени» как лакмус зрелости
PITR (Point-in-Time Recovery) решает типовую боль: нужно не «поднять ночной бэкап», а откатиться на 12:47:30, когда ещё не выполнили ошибочный запрос или не приехала поломанная миграция.
В managed database PITR часто включён «из коробки»: сервис делает базовые бэкапы и архивирует WAL, а вы выбираете точку восстановления в пределах периода хранения. Но проверьте нюансы заранее:
Период хранения WAL и снапшотов: часы, дни, недели.
Точность: до секунды или «крупными шагами».
Можно ли восстановиться в новый инстанс, не трогая текущий (удобно для расследований).
На VDS PITR тоже полностью реален, но требует дисциплины: стабильные base backup, непрерывная архивация WAL, контроль объёма архива, тесты восстановления и понятный runbook.
Если вам нужен практический разбор «что включать и как проверять», держите отдельную заметку: как устроить PITR в PostgreSQL: WAL, base backup и восстановление.
Минимальный скелет PITR на VDS (для понимания объёма работ)
Ниже не «готовый прод-рецепт на все случаи», а ориентир: какие сущности должны появиться в конфигурации и в регламенте.
sudo -u postgres psql -c "SHOW wal_level;"
sudo -u postgres psql -c "SHOW archive_mode;"
sudo -u postgres psql -c "SHOW archive_command;"Дальше вам нужен инструмент бэкапа (например, pgBackRest), хранилище для архивов и регулярная проверка восстановления на отдельном контуре. Именно тест восстановления обычно вскрывает «PITR настроен, но не работает».
Производительность и предсказуемость: где проще «вытянуть» Postgres
Вопрос «что быстрее» для PostgreSQL редко решается абстрактно. Важнее предсказуемость и возможность влиять на узкие места.
На VDS у вас больше рычагов:
Выбор диска/томов, контроль задержек, отдельный том под WAL.
Контроль лимитов ОС и процессов, изоляция базы от соседних сервисов.
Своя стратегия connection pooling (PgBouncer и аналоги) и лимитирование «шторма коннектов» со стороны приложения.
У managed database часто есть профили и лимиты: нельзя менять часть параметров, ограничены расширения, есть квоты на соединения, фоновые работы и обслуживание могут быть не полностью прозрачны. Зато сервис обычно защищён от некоторых классов ошибок (например, «убили диск логами»), если вы не выходите за рамки его модели.
Про «как укротить autovacuum, bloat и индексы» полезно иметь отдельный чек-лист: практический тюнинг autovacuum и индексов в PostgreSQL.
Безопасность: доступы, сеть, шифрование, аудит
По безопасности разница обычно упирается в модель доверия и границы контроля.
VDS: максимум контроля, но всё на вас
Вы сами отвечаете за:
Сетевую сегментацию (закрыть порт базы от всего мира, дать доступ только из нужных подсетей).
Политику пользователей/ролей PostgreSQL, ротацию паролей, использование сертификатов.
Обновления ОС и пакетов PostgreSQL, управление уязвимостями.
Шифрование бэкапов, контроль доступа к архивам, аудит действий администраторов.
Если клиент и приложение ходят к базе по сети (а не по локальному сокету), почти всегда имеет смысл включать TLS. Для публичных сервисов и административных панелей вокруг базы (мониторинг, бэкап-репозитории, внутренние порталы) пригодятся SSL-сертификаты с нормальным жизненным циклом и ротацией.
Managed database: меньше возможностей ошибиться, но меньше прозрачности
Часть задач закрыта провайдером: патчи, базовая изоляция, иногда встроенный аудит. Но перед выбором уточните:
Кто имеет административный доступ на уровне платформы и как это регулируется.
Как устроены логи и аудит: можно ли выгружать события и хранить их у себя.
Какие есть сетевые политики: allowlist, приватные сети, доступ только из определённых подсетей.
Обновления и миграции версий: где меньше риска «сломать прод»
Плановые обновления — то, что в долгую съедает много нервов. В PostgreSQL важны и minor-обновления безопасности, и major-апгрейды с возможной несовместимостью.
Managed database часто предлагает автоматические патчи и управляемые окна обслуживания. Это снижает риск «забыли обновиться», но может конфликтовать с вашими релизными окнами и требованиями к простоям.
VDS даёт полный контроль: можно поднять стенд, прогнать нагрузочные тесты, выполнить апгрейд через реплику или логическую репликацию, планировать всё до минуты. Цена — необходимость иметь экспертизу и время на корректный план.
Операционная рутина: бэкапы, мониторинг, алерты, on-call
В продакшене PostgreSQL — это не только запросы. Это ежедневная эксплуатация:
Проверка бэкапов и регулярные тесты восстановления.
Мониторинг лагов репликации, места на диске, роста WAL, autovacuum, блокировок.
Алерты не «на всё подряд», а на симптомы реальных инцидентов.
Runbook: что делать при переполнении диска, падении реплики, росте задержек.
В managed database часть рутины закрыта сервисом, но в ловушку «управляемый — значит можно не думать» попадать нельзя: думать придётся про лимиты, квоты, стоимость масштабирования и пул соединений на стороне приложения.
Практические сценарии: что выбрать в типовых случаях
Сценарий 1: стартап/проект без DBA, важна скорость запуска
Если команда маленькая, а база нужна «чтобы работало», managed database обычно выигрывает: меньше времени на настройку, меньше шансов забыть про бэкапы и PITR, проще вписаться в базовый SLA.
Сценарий 2: продукт с нестандартной конфигурацией и требованиями к контролю
Если нужны специфические расширения, тонкие настройки, жёсткий сетевой периметр и прозрачность на уровне ОС, своя база на VDS чаще оказывается правильнее.
Сценарий 3: критичный сервис, где простои дороги
Здесь решает не вывеска, а зрелость процессов. Managed database может дать HA быстрее «из коробки». Но если вам нужен контролируемый high availability с понятным поведением при сбоях и отработанными учениями, собственный кластер на VDS тоже отличное решение — при условии, что вы готовы его эксплуатировать.
Сценарий 4: предсказуемая нагрузка и строгий бюджет
На VDS проще оптимизировать стоимость, особенно если вы точно понимаете профиль нагрузки. У managed database ценник может расти из-за ступенчатого масштабирования и оплаты управляемых функций.
Как принять решение без гадания: минимальный план оценки
Опишите требования: RPO/RTO, период хранения бэкапов, нужен ли PITR, требования к SLA.
Соберите профиль нагрузки: TPS, размер базы, рост, число соединений, доля чтения/записи.
Сравните ограничения managed database: параметры, расширения, лимиты коннектов, сетевые политики.
Посчитайте TCO в двух вариантах: стоимость ресурсов плюс стоимость часов инженеров и стоимость риска простоя.
Проведите огневое учение на тестовом контуре: восстановление из бэкапа, PITR, имитация падения узла.
Итог: краткая памятка выбора
Берите managed database, если важнее быстрый запуск, типовые требования, предсказуемый SLA и минимум рутины, а ограничения сервиса вас устраивают.
Берите PostgreSQL на VDS, если нужен полный контроль, нестандартные настройки, прозрачность, возможность построить свой HA и управлять PITR так, как удобно вашему продукту.
Главное: какой бы вариант вы ни выбрали, успех определяется не тем, «где стоит Postgres», а тем, насколько чётко определены требования (RPO/RTO), настроены бэкапы и регулярно проверяется восстановление.
