Managed PostgreSQL или свой VPS: во сколько обходятся бэкапы и дежурство

Кто будет восстанавливать базу в выходной? Вопрос звучит скучно, но именно с него стоит начинать сравнение managed PostgreSQL и собственной базы на VPS. Строка в счёте за хостинг показывает только часть цены. Вторая часть измеряется не рублями, а часами внимания: кто-то должен проверять копии, читать заметки о выпуске, следить за диском и просыпаться, когда что-то пошло не так. Эти часы есть в обоих вариантах. Различается лишь то, кому они принадлежат.

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

Сначала договоримся, что именно сравниваем

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

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

• Допустимая потеря данных. Сколько последних минут работы вы готовы потерять в худшем случае. «Ночной дамп» означает потерю до суток, и это нормальный ответ для внутреннего инструмента, но не для магазина.
• Допустимое время восстановления. Час, четыре часа или «до утра понедельника».
• Окно обслуживания. Можно ли остановить базу на несколько минут для обновления или нужно обходиться без остановок.
• Срок хранения копий. Неделя, месяц, год: от этого зависит объём хранилища.

Managed PostgreSQL не есть единый набор гарантий. Один провайдер даёт восстановление на момент времени из коробки, другой только ночные снимки, третий требует включать нужное отдельно и за доплату. Поэтому конкретный план проверяйте по его описанию и сопоставляйте с этими четырьмя пунктами. Для VPS всё наоборот: возможно почти что угодно, но каждое обещание вы даёте себе сами.

Ежемесячный счёт: инфраструктура и труд

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

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

Как оценивать часы, не обманывая себя

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

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

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

Разовая работа: настройка и первые обновления

Теперь то, что платится один раз, но обычно забывается в расчётах. На управляемой базе стартовая работа короткая: создать экземпляр, настроить доступ по сети, завести роли, прогнать миграции. Если вы переезжаете с облачной платформы, добавится перенос данных. Например, Heroku PGBackups, по документации, использует формат custom от pg_dump, и такой экспорт можно восстановить в другую PostgreSQL (Heroku: импорт и экспорт). Там же отмечено, что дамп и восстановление нагружают базу, а для загруженной базы это значит планировать окно, а не запускать копирование в разгар рабочего дня.

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

Переезд: что дамп сохраняет, а что нет

При переносе дампом есть тонкости, которые легко пропустить. По документации, pg_dump делает согласованный экспорт одной базы, даже когда в неё параллельно пишут и читают. Но роли и tablespaces в дамп одной базы не входят: для глобальных объектов предназначен pg_dumpall (документация pg_dump). На практике это значит, что после восстановления в новом месте приложение может не подключиться только потому, что не создана нужная роль. Это первое, что стоит записать в план переезда.

Вторая тонкость связана с версиями. Инструмент pg_dump не работает с сервером более новой основной версии, чем он сам, а восстановление в более старый сервер не гарантировано. Отсюда практическое правило: ставьте на машину, с которой снимаете дамп, клиентские утилиты не старше сервера-источника, а целевую версию выбирайте не ниже исходной. Архивные форматы восстанавливаются через pg_restore, обычный SQL через psql. Выбор формата определяет и способ возврата, поэтому решайте его заранее, а не в день переезда.

Обновления: регулярная работа, а не событие

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

Для небольшой базы ресурсы подбирают по размеру данных и нагрузке. У VPS MAATRIX линейка тарифов начинается с 1 vCPU, 2 ГБ RAM и 40 ГБ NVMe (Ba) и доходит до 16 vCPU, 32 ГБ и 320 ГБ (Djed). Это параметры плана, а не обещание ёмкости: для вашей базы реальную нагрузку нужно мерить на тестовом прогоне. Для базы важны быстрый диск и память под кэш, а NVMe и root-доступ позволяют настроить систему под PostgreSQL самостоятельно.

Копия и запасной узел: два разных ответа на две разные беды

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

Копия, которая умеет возвращаться во времени

Для возврата на выбранный момент PostgreSQL использует связку базовой файловой копии и архива журнала упреждающей записи (WAL). По документации, такое восстановление воспроизводит изменения до нужной точки, но одной базовой копии для произвольной точки мало: нужен непрерывный диапазон WAL с момента её создания (непрерывное архивирование и PITR). Там же сказано, что восстановление создаёт отдельную временную линию, а архивирование и возврат требуют планирования.

Для расчёта отсюда следуют три практических вывода:

1. Место под копии считается не только по размеру базы: к базовым копиям добавляется поток WAL за весь срок хранения. Чем интенсивнее запись, тем он больше.
2. Пропуск в архиве WAL ломает возможность вернуться в точку после этого пропуска. Значит, нужно следить за самим архивированием, а не только за тем, что файлы «где-то лежат».
3. Восстановление нужно репетировать. Копия, которую ни разу не разворачивали, остаётся гипотезой.

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

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

Запасной узел: отдельная статья расходов

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

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

Считаем год для небольшой команды

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

Реальные платежи за год:

• M — месячный тариф управляемой базы с нужными вам копиями, умноженный на 12;
• V — месячная плата за VPS, умноженная на 12;
• S — хранилище внешних копий для VPS за год;
• R — второй VPS под реплику, если он вам нужен, и аналогичная опция у управляемого сервиса.

Оценка времени (не платёж, пока вы не решили оценивать его в деньгах):

• H1 — часы в год на повседневное обслуживание своей базы: проверки, обновления, реакция на оповещения;
• H0 — часы в год на то же при управляемом сервисе;
• Hs — разовая настройка на VPS и репетиция восстановления;
• Hu — работа над обновлением основной версии, если оно попадает в год.

Тогда разница в платежах равна M − (V + S), а дополнительная нагрузка на команду равна (H1 − H0) + Hs + Hu. Если ставка часа вашего специалиста равна C, то точка безубыточности по году наступает, когда выполняется условие:

M − (V + S) = C × ((H1 − H0) + Hs + Hu)

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

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

• Размер базы. Чем больше данные, тем дороже хранилище копий и дольше восстановление. Для очень маленькой базы управляемый сервис по цене может оказаться почти неотличимым от VPS.
• Число баз. Несколько небольших баз можно разместить на одном VPS, и постоянные затраты на обслуживание разделятся между ними. Управляемые планы часто тарифицируются за экземпляр.
• Опыт команды. Если в команде есть человек, который уже настраивал PostgreSQL и репетировал восстановление, Hs заметно меньше. Если нет, учебное время стоит включить в расчёт честно.
• Требования к сохранности. Строгое окно возврата и быстрый переход на запасной узел сильно увеличивают правую часть уравнения при самостоятельной эксплуатации.

Где на VPS живёт база небольшой команды

Если расчёт склоняется к своему серверу, на практике вы начнёте с тарифа, где памяти хватает под кэш PostgreSQL, а диска с запасом под данные и рост журнала. Для небольшой базы подойдут ресурсы уровня Uab (2 vCPU, 4 ГБ, 80 ГБ) или Heka (4 vCPU, 8 ГБ, 160 ГБ), но это ориентиры, а не гарантия: окончательный выбор делается по замеру на ваших данных. Хорошая новость в том, что тариф можно пересматривать по мере роста нагрузки, а локацию выбрать ближе к приложению: в предложении указаны Великобритания, США, Россия и Франция. Точное наличие образов и операционных систем в каждой локации проверяйте в форме заказа.

Если же рядом с базой нужно запустить и другие сервисы, например автоматизацию n8n или Nextcloud, их установка есть в каталоге MAATRIX. Но держать их на одном сервере с боевой базой стоит осторожно: общая память и диск связывают нагрузку, и пик одного сервиса отразится на другом.

Граница, которую вы подписываете вместе с экономией

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

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

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