Управляемый PostgreSQL против самостоятельного хостинга:
реальные компромиссы
Самостоятельный хостинг PostgreSQL выглядит дёшево в таблице. Одна VM, одна база данных, без наценки за управляемый сервис. Но в таблице не хватает большей части затрат. Правильно эксплуатируемый PostgreSQL требует постоянного внимания SRE — которое большинство команд недооценивает, пока что-то не ломается в 2 часа ночи и никто не знает конфигурацию Patroni достаточно хорошо для failover без потери данных.
Что реально требует самостоятельный хостинг
Производственный кластер PostgreSQL — это не VM с установленным Postgres. Выполненный правильно, он требует: начальной настройки shared_buffers (обычно 25% RAM), work_mem, max_connections (сбалансировано с конфигурацией PgBouncer), checkpoint-настроек для предотвращения I/O-пиков. Мониторинга: pg_stat_activity для насыщения соединений, отставания репликации, обнаружения долгих запросов. Автоматического переключения при сбое — Patroni с etcd/Consul или pg_auto_failover — с протестированным runbook. Архивирования WAL в объектное хранилище для PITR, тестируемого ежеквартально. И патчинга ОС, не ломающего службу Postgres.
Self-Hosted PostgreSQL: операционный чек-лист
-
Начальная настройка — shared_buffers, work_mem, max_connections, checkpoint_completion_target, effective_cache_size. Неверные значения вызывают незаметные регрессии производительности, проявляющиеся через недели.
-
Стек мониторинга — pg_stat_activity, отслеживание отставания репликации, мониторинг раздутия (dead tuples от задержки VACUUM), журнал медленных запросов с pg_stat_statements.
-
Автоматизация failover — Patroni или pg_auto_failover с правильно настроенным кворумом DCS (etcd/Consul) для предотвращения split-brain. Требует регулярного тестирования — непроверенный failover не является failover.
-
Резервное копирование и PITR — Архивирование WAL в отдельное хранилище, тестируемые восстановления, задокументированный RPO. pgBackRest или Barman — стандартный выбор. Резервные копии, которые никогда не восстанавливались, — не резервные копии.
-
Обслуживание ОС — Обновления ядра, патчи безопасности, настройка huge pages и лимитов ulimit без нарушения жизненного цикла службы Postgres.
Что делает управляемый PostgreSQL
Хорошо построенный управляемый сервис устраняет весь операционный слой выше. Автоматический failover срабатывает менее чем за 60 секунд. Почасовые резервные копии с PITR — стандарт. PgBouncer-пулинг соединений встроен. Патчинг минорных версий применяется автоматически. Мониторинг показывает нужные метрики без необходимости строить инфраструктуру сбора и оповещения.
Управляемый PostgreSQL даёт
- • Автоматический failover менее 60 секунд
- • Почасовые резервные копии + PITR
- • Встроенный пулинг соединений PgBouncer
- • Автоматический патчинг минорных версий
- • Встроенный мониторинговый дашборд
- • Предварительно настроенная потоковая репликация
Self-hosted оправдан для
- • Нестандартных расширений в масштабе (PostGIS, TimescaleDB)
- • Датасетов более 10 ТБ с нестандартными стратегиями партиционирования
- • Регуляторных требований к управлению ключами шифрования
- • Команд с уже имеющимся выделенным DBA
Реальное сравнение стоимости
Self-hosted PostgreSQL требует 0,3–0,5 FTE времени SRE для правильной эксплуатации. При среднерыночной зарплате SRE в Ташкенте около $3 000/мес это $900–$1 500/мес только на труд. VM на 4 ядра и 16 ГБ для базы данных стоит около $200/мес. Итого: $1 100–$1 700/мес.
Управляемый экземпляр PostgreSQL 4 ядра 16 ГБ на Hyper App стоит около $600–800/мес — полностью управляемый, со всем вышеперечисленным включённым. Это более низкая абсолютная стоимость при меньшем операционном риске, а не компромисс. Self-hosted выигрывает по стоимости только если у вас уже есть незагруженные SRE — и тогда у вас другая проблема.
«Мы потратили девять месяцев на отладку периодического отставания репликации в нашем self-hosted кластере. Первопричиной оказалось неправильное значение checkpoint_segments. С управляемым PostgreSQL весь этот класс проблем исчезает.»
— Backend Lead, центральноазиатская SaaS-компания
Как принять решение
Если у вашей команды нет выделенного DBA или SRE — управляемый является правильным выбором, стоимость с учётом риска ниже даже без учёта инцидентов в 2 ночи. Если ваши данные имеют специфические требования к партиционированию или расширениям, которые управляемые сервисы не поддерживают, — self-hosted оправдан. Для большинства производственных нагрузок PostgreSQL в диапазоне 10 ГБ–2 ТБ управляемый — лучшее инженерное решение, а не просто более удобное.