Управляемая база данных против самостоятельного Postgres для SaaS‑команд

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

Растущая SaaS‑компания редко платит только за сервер базы данных. Она платит за всё вокруг него. Месячная цифра на странице управляемой базы или виртуальной машины выглядит просто, но она не отражает работы, нужной чтобы сохранить данные клиентов и держать приложение онлайн.

Именно поэтому команды часто неверно формулируют этот выбор. Они сравнивают управляемый сервис за $300 и VM за $90 и считают, что VM выигрывает. На бумаге — возможно. В жизни кому‑то всё равно придётся настроить бэкапы, прогнать тесты восстановления, проводить обновления, следить за ростом диска, реагировать на медленные запросы, ротировать секреты и просыпаться по сигналам в 2:00.

Эти задачи не остаются маленькими долго. Хобби‑приложение может жить с шероховатостями. SaaS с платящими пользователями — нет. Как только растут регистрации, объём данных и нагрузка поддержки, каждая пропущенная проверка бэкапа или отложенный патч начинают иметь реальную стоимость.

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

Риск тоже важен. Управляемый сервис может стоить дороже, но часто включает автоматизацию, встроенные бэкапы, более простое переключение при отказе и гладкий путь обновлений. Самохостинг всё ещё может быть лучшим вариантом, но только если ваша команда умеет хорошо эксплуатировать Postgres и у неё есть запас времени поддерживать это по мере роста продукта.

Для растущей SaaS цена из прайс‑листа — только первая цифра. Реальное сравнение включает инструменты, обновления, бэкапы, мониторинг, нагрузку on‑call и стоимость отвлечения опытных людей от работы над продуктом.

Что нужно учесть перед сравнением вариантов

Честное сравнение начинается с двух корзин: деньги, отданные вендорам, и время команды, потраченное на поддержание Postgres в рабочем состоянии. Команды обычно учитывают сервер, хранилище и трафик, а потом забывают про человеческую работу вокруг. Так уходит большая часть счёта.

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

Нужно также учитывать вспомогательные инструменты. Бэкапы не бесплатны только потому, что существует pg_dump. Кому‑то нужно их расписать, прогонять тесты восстановления, поддерживать достаточную ретенцию и следить, чтобы они работали после изменений схемы. То же касается мониторинга, логов, оповещений и трекинга ошибок. Если вам нужны отдельные инструменты для метрик, дашбордов или pager‑оповещений, включите их в расчёт.

Обновления заслуживают отдельной строки. Переход на новую мажорную версию Postgres требует планирования, прогонов в тестовой среде, проверок приложения и подготовки отката. Управляемые сервисы обычно снимают часть этой работы, но не всю. При самохостинге ваша команда владеет полным планом действий.

Время on‑call легко игнорировать, потому что оно не появляется в подписке. Но оно стоит денег. Если инженер проводит три вечера в месяц, решая проблемы с диском, лаги репликации или неудачные бэкапы, это время должно быть в сравнении. То же верно для последующей работы по инциденту, разборов и очистки на следующий день.

Простой способ отслеживать расходы — разбить их на пять групп:

• регулярные траты на вычисления, хранилище, бэкапы, мониторинг, оповещения и логирование
• рутинное время операторов на обслуживание, патчи, проверки, тесты восстановления и вопросы поддержки
• разовая работа по настройке: миграция, автоматизация, дашборды, правила доступа и failover
• работа по обновлениям: репетиции, тестирование приложения, окна обслуживания и подготовка отката
• время на инциденты: реагирование on‑call, восстановление и последующие исправления

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

Что обычно включает цена управляемой базы

Счёт за управляемую базу обычно начинается с базовой платы за инстанс, хранилища, места для бэкапов и иногда IOPS или сетевых расходов. Некоторые провайдеры также выставляют счёт за read‑реплики, кросс‑региональные копии или за расширенную ретенцию. Эта месячная сумма часто покрывает гораздо больше, чем CPU и диск.

Вы платите и за работу, которую провайдер снимает с ваших плеч. Это часто включает автоматические бэкапы, точечное восстановление (PITR), health‑проверки, замену упавших узлов и базовый мониторинг с оповещениями. Если диск падает в 3 утра, вашей команде зачастую не нужно заходить и перестраивать сервер.

Патчи и failover важнее заголовка цены. Многие сервисы автоматически применяют мелкие обновления Postgres, патчи ОС и промоут реплик. Некоторые даже тестируют пути failover за кулисами. Это снижает время операторов, даже если строчка в счёте выше, чем у самохостинга.

Цена за контроль. Управляемый Postgres часто ограничивает superuser‑доступ, кастомные конфигурации и некоторые расширения. Если вам нужны pgvector, PostGIS, logical replication или нетривиальная настройка, проверьте детали, прежде чем считать, что управляемый вариант подойдёт.

Перед сравнением цен ответьте на простые вопросы. Что включает базовая плата, а что меряется отдельно? Какие расширения и админ‑действия доступны вашей команде? Кто отвечает за патчи, failover и тесты восстановления? Когда происходят окна обслуживания и можно ли их выбирать? Сколько стоит более длительная ретенция бэкапов после дефолтного окна?

Провайдер может выглядеть дорогим при $400 в месяц, но эта цена может включать ежедневные бэкапы, семь дней PITR, standby‑узел, автоматическое патчирование и быстрый failover. Дешёвый план, который оставляет тесты восстановления, планирование обновлений и реагирование на инциденты вашей команде, на самом деле не дешевле — он просто переносит стоимость с инвойса на ваш календарь.

Что действительно добавляет к счёту самохостинг

Самохостинг Postgres редко стоит лишь «одну VM и немного дисков». Базовая цена сервера — простая часть. Реальный счёт растёт вокруг неё, и именно там команды обманывают сами себя.

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

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

И есть часть, которая больше всего меняет экономику: человек, который отвечает за базу каждую неделю. Если инженер тратит даже три‑пять часов в неделю на уход за Postgres, это реальная стоимость. Это также упущенная возможность — этот инженер не исправляет баги биллинга, не улучшает онбординг и не выпускает следующую фичу, которую просили клиенты.

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

Безопасность добавляет своей работы: расписания патчей, ротация секретов, правила файрвола, доступ по принципу наименьших привилегий, журналы аудита и явный ответственный при подозрениях в 2:00. Управляемые сервисы упаковывают большую часть этой работы в цену. Самохостинг перекладывает её на вашу команду.

Именно поэтому это не вопрос только прайс‑листа. Самохостинг может быть дешевле, но только если вы считаете всю систему вокруг БД и человека, который её поддерживает.

Как провести справедливое сравнение затрат

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

Потом положите время операторов в ту же таблицу, что и инфраструктуру. Самохостинг часто выглядит дешевле, пока вы не посчитаете часы на патчи, обновления версий, мониторинг, проверки бэкапов, тесты восстановления и on‑call. Даже внимательная команда может тратить три‑пять часов в неделю на это. Умножьте часы на реальную почасовую цену, а не на догадку.

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

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

Сравнивайте итоги за 12 месяцев. Месячные цены скрывают проекты по обновлению, неожиданный рост хранилища и время, потраченное на мелкие проблемы до того, как они перерастут в большие. Управляемые сервисы часто объединяют несколько задач в один счёт. Самохостинг обычно разбивает их на отдельные статьи плюс время операторов.

Используйте один реалистичный сценарий, а не стопку фантазий. Если вы ожидаете рост на 30%, моделируйте именно его и придерживайтесь. Затем добавьте один стресс‑кейс для запуска продукта или крупного клиента с повышенной нагрузкой.

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

Простой пример для SaaS

Представьте трёхчленную команду SaaS, которая выпускает релизы каждую неделю. Один занятой backend‑инженер отвечает за API, базу данных, большинство продакшен‑инцидентов и часть поддержки. Трафик сначала небольшой, затем за полгода быстро растёт по мере прихода платящих клиентов.

Сначала самохостинг кажется дешевле. Нормальная VM под Postgres может стоить $80 в месяц, тогда как управляемая база с автоматическими бэкапами, failover, патчами и оповещениями — $220. Если остановиться только на этом, математика кажется простой.

Но всё меняется, когда вы считаете время инженера. Даже в спокойный месяц кому‑то нужно проверить бэкапы, прогнать тест восстановления, следить за ростом хранилища, планировать обновления версий, просматривать медленные запросы и убеждаться, что релизы не повредят базу. Если это занимает три часа в месяц, а инженер стоит $90 в час со всеми расходами, то это $270 в операторском времени. Дешёвый сервер уже перестал быть выгодным.

Добавьте еженедельные релизы. Каждый релиз повышает шанс проблемы миграции, пропущенного индекса или запроса, который замедляется под реальной нагрузкой. Управляемый сервис не убирает эти риски полностью, но снимает часть забот вокруг них. Это важно, когда один человек и так перегружен.

Одна тяжёлая ночь может перевернуть всё решение. Допустим, пятничный релиз увеличил запись, WAL‑файлы растут быстрее, чем ожидали, и диск базы достигает лимита в 1:20 ночи. Инженер тратит четыре часа на восстановление записи, затем теряет половину следующего дня на исправления оповещений, чистку и проверку бэкапов. Этот один инцидент может стоить больше, чем несколько месяцев разницы в цене, не считая усталости, отложенной работы над продуктом и раздражённых клиентов.

В этот момент это уже не только вопрос хостинга. Это кадровый вопрос. Если команда маленькая, трафик растёт, и один инженер держит продакшен, управляемый вариант часто выигрывает, даже если список плат больше.

Самохостинг всё ещё может иметь смысл. Если нагрузка стабильна, команда хорошо знает Postgres, и у кого‑то в обязанности входит бэкапы, обновления и тесты восстановления, более низкий счёт может быть реальным. Смысл не в том, что один вариант всегда выигрывает. Смысл в том, что более дешёвый счёт и действительно более дешёвый выбор часто разные вещи.

Ошибки команд при раннем самохостинге

Первая ошибка простая: команды сравнивают управляемый план с самой дешёвой VM и на этом останавливаются. VM за $60 может выглядеть лучше, чем сервис за $300, но эта математика рушится, когда кому‑то нужно патчить Postgres, следить за ростом диска, чинить задания бэкапа и отвечать на оповещения в 2 дня ночи. Месячный счёт — всего одна часть билла.

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

Обновления трактуют так же. Команды считают, что прыжок версии рутинный, а затем сталкиваются с проблемами расширений, совместимости клиентов или миграцией, которая занимает дольше, чем ожидалось. Даже маленькое обновление Postgres нуждается в прогоне в тестовой среде, плане отката и времени в календаре.

Уход сотрудников бьёт сильнее, чем думают основатели. Один инженер настраивает репликацию, удержание WAL и оповещения. Через полгода он уходит, и остальные относятся к базе как к стеклянной коробке. Она ещё работает, но никто не хочет её трогать. Отсутствие заметок, слабая передача и простой страх добавляют затрат.

Стресс on‑call — ещё одна плата, которой нет в счёте. Когда одного инженера будят по ложной тревоге, компания платит за это на следующий день сниженной продуктивностью и хуже принятыми решениями. Малые команды часто ведут себя так, будто это бесплатно, потому что никто не выставляет отдельный счёт.

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

Если в вашей SaaS нет явного ответственного за уход за базой каждую неделю, самохостинг обычно преждевременный. Платить больше за сервис может оказаться дешевле, чем расплачиваться предотвратимыми простоями, потерянным сном и разбросанным временем операторов.

Когда самохостинг всё ещё оправдан

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

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

Самохостинг также лучше, когда у вас уже есть люди, умеющие это хорошо запускать. SaaS‑команда с сильным ops‑инженером или дробным CTO, который работал с бэкапами, failover, мониторингом и обновлениями в продакшне, сильно меняет расчёт. Время операторов остаётся затратой, но не одна и та же для всех команд.

Несколько признаков, что стоит смотреть в сторону самохостинга:

• вам нужны настройки или расширения, которые провайдер не разрешает
• у компании строгий контроль данных или требования приватной сети
• нагрузка достаточно стабильна, чтобы вы могли правильно подобрать серверы
• ваша команда уже управляет Linux, мониторингом и дежурствами без сильного стресса

Форма трафика важнее мнений. B2B‑SaaS со стабильной дневной нагрузкой в будние дни гораздо проще держать на самохостинге, чем приложение с резкими всплесками в произвольное время. Цели по аптайму тоже важны. Если клиенты ожидают очень высокой доступности в разных часовых поясах, самохостинг имеет смысл только при тестированном failover, ясных оповещениях и регулярных проверках восстановления.

Простой пример: растущая SaaS с предсказуемым трафиком, одним опытным инженером по инфраструктуре и готовыми инструментами мониторинга может за год тратить меньше на самохостинге. Эта команда делит бэкапы, алерты, логирование и деплой‑инструменты по всему стеку. База не сидит отдельно, и дополнительная работа остаётся управляемой.

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

Если ваша команда не может быстро и уверенно восстановить вчерашний бэкап на чистый сервер — подождите с самохостингом.

Быстрая проверка перед решением

Дешевая месячная цена может скрывать много работы. Прежде чем выбирать, выпишите, кто будет выполнять постоянные задачи по базе.

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

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

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

Ночи, выходные и праздники важнее, чем признаются. Если база тормозит во время релиза или сигнал диска срабатывает в 2:00, кто реагирует? Если ответ «кто заметит первым», у вас нет ясной операционной модели.

Короткий чек‑лист:

• назначьте одного человека ответственным за бэкапы и тесты восстановления
• назначьте одного человека ответственным за обновления и планы отката
• оцените месячные часы на рутинное обслуживание, не только на экстренные случаи
• решите, кто покрывает инциденты вне рабочего времени
• проверьте, сможет ли текущая команда взять это без задержек в продуктовой работе

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

Что делать дальше

Перестаньте гнаться за самой низкой месячной ценой. Выберите вариант, который ваша команда сможет поддерживать без паники, когда бэкап упадёт, диск заполнится или обновление зайдёт в спринт.

Для многих небольших SaaS ответ не в цене вычислений, а в том, кто делает скучную, но рискованную работу каждую неделю. Если сегодня в команде нет владельца этой работы, самохостинг часто обходится дороже, чем кажется.

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

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

Если числа близки, внешний аудит помогает. Oleg Sotnikov на oleg.is работает со стартапами и растущими компаниями по инфраструктуре, техническому лидерству и практическим AI‑first операциям и может помочь честнее оценить эти компромиссы.

Хороший следующий шаг прост: соберите одностраничный лист затрат, назначьте ответственных и поставьте дату пересмотра после следующего этапа роста.