Managed PostgreSQL vs PostgreSQL на VPS что выбрать по цене, SLA, бэкапам и контролю

Выбор между Managed PostgreSQL и PostgreSQL на VPS — это не сравнение «дорогого» и «дешёвого» тарифа, а решение о границе ответственности. VPS даёт максимум контроля над сервером, расширениями, ОС и конфигурацией, но команда сама отвечает за бэкапы, PITR, мониторинг, патчи, HA, восстановление и инциденты.

Managed PostgreSQL обычно дороже в счёте провайдера, зато снижает операционную нагрузку и делает понятнее SLA, резервное копирование, восстановление и отказоустойчивость — если нужные возможности включены в тариф. Он чаще подходит для критичных B2B-сервисов, SaaS и интернет-магазинов, где простой и потеря данных быстро превращаются в деньги, штрафы и репутационный ущерб.

VPS оправдан, когда нужен root-доступ, редкие расширения, нестандартная конфигурация или низкая цена простоя. Финальное решение стоит принимать по TCO, RPO/RTO, требованиям к доступности и способности команды восстановить сервис во время инцидента, а не по цене инстанса в прайсе.

Почему выбор не сводится к цене инстанса

На встрече это часто выглядит почти очевидно: VPS за $10–20 в месяц, рядом Managed PostgreSQL за $15–50+ и выше. PostgreSQL один и тот же, значит, зачем платить больше?

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

Разница между PostgreSQL на VPS и managed-сервисом не в том, «платная» база или «бесплатная». Разница в том, кто несёт операционную ответственность.

VPS даёт больше контроля: root-доступ, свои расширения, нестандартные настройки ОС и PostgreSQL. Managed PostgreSQL стоит дороже как сервис, зато часть рутины — резервное копирование, обслуживание, метрики, SLA, PITR или HA в зависимости от тарифа — уже вынесена на сторону провайдера.

Ключевые вопросы выбора обычно сводятся к четырём осям:

• Сколько решение стоит в полной стоимости владения, а не только в тарифе;
• Какой уровень восстановления и доступности нужен бизнесу;
• Есть ли внутри команды время и компетенции на эксплуатацию PostgreSQL;
• Насколько критичны полный контроль, специфичные расширения и нестандартная конфигурация.

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

Главная развилка — не PostgreSQL, а зона ответственности

Прежде чем считать TCO, нужно понять, за что именно платит команда: деньгами, временем инженеров или риском. На первый взгляд выбор простой — где запустить PostgreSQL. На практике команда выбирает, кто будет проверять резервные копии, ставить патчи, реагировать на алерты и отвечать перед бизнесом, если база не поднялась после сбоя.

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

Чтобы не смешивать контроль, цену и надёжность в один спор, сначала стоит разложить ответственность по ключевым зонам.

Сервер, ОС и базовая инфраструктура

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

В Managed PostgreSQL инфраструктурный слой берёт на себя провайдер в рамках сервиса. Команда не управляет сервером напрямую, зато меньше занимается операционной рутиной вокруг ОС и базовой инфраструктуры.

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

Установка, параметры и расширения PostgreSQL

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

В managed-сервисе база обычно уже преднастроена, а часть параметров доступна через панель, API или тариф. Но свобода ограничена политиками провайдера:

• Не все расширения разрешены;
• Не все параметры можно менять напрямую;
• Настоящий root-доступ к серверу обычно недоступен;
• Обновления и обслуживание проходят по правилам сервиса.

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

Контроль над параметрами важен, но его мало. Любую конфигурацию нужно поддерживать в актуальном и безопасном состоянии — и здесь появляется отдельная зона ответственности.

Обновления, патчи и обслуживание

На VPS обновления нужно планировать, тестировать и ставить самостоятельно. Команда сама решает, когда обновлять ОС, PostgreSQL, расширения и связанные компоненты, но также сама отвечает за последствия задержек или неудачного обновления.

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

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

Бэкапы и восстановление

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

В Managed PostgreSQL часто есть автоматические бэкапы и инструменты восстановления. Но условия зависят от тарифа, поэтому перед выбором нужно проверить:

• Как часто создаются копии;
• Сколько они хранятся;
• Есть ли PITR и на какой период;
• Где физически лежат копии;
• Сколько стоит дополнительное хранение;
• Как запускается восстановление и кто за него отвечает.

Автоматические бэкапы снижают риск, но не снимают вопрос доступности. Бизнесу важно не только вернуть данные, но и понять, сколько времени сервис будет недоступен.

Мониторинг, SLA и отказоустойчивость

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

В Managed PostgreSQL базовые метрики, часть алертов, SLA и HA могут быть встроены в сервис или доступны как опции. Но это не магическая защита от всех проблем. Отдельно нужно проверить:

• На что именно распространяется SLA;
• Нужен ли резервный узел для заявленной доступности;
• Есть ли автоматическое переключение при отказе;
• Какие окна обслуживания и исключения прописаны;
• Как приложение переживает переключение.

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

Оптимизация запросов и архитектура приложения

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

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

Для B2B это важно не только технически. Граница ответственности определяет, кто несёт стоимость простоя, кто держит дежурства, кто подтверждает восстановление перед клиентами и кто объясняет нарушение внутренних или внешних SLA.

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

TCO: из чего складывается реальная стоимость PostgreSQL

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

На первый взгляд VPS выигрывает: сервер за $10–20 выглядит дешевле managed-инстанса. Но если инженер каждый месяц тратит несколько часов на патчи, проверку бэкапов, алерты и разбор сбоев, эта работа тоже становится частью стоимости. Просто она спрятана не в счёте провайдера, а в загрузке команды.

Честное сравнение начинается не с одной строки в прайсе, а со всех расходов, которые появляются вокруг PostgreSQL в рабочей среде.

Инфраструктура: сервер, диски и производительность

Первый слой TCO — ресурсы, на которых работает база. На VPS команда сама выбирает сервер, запас CPU/RAM, тип дисков, объём хранилища и производительность. В managed-сервисе часть этих параметров входит в тариф, но рост нагрузки почти всегда увеличивает стоимость.

У VPS больше гибкости в выборе конфигурации, но больше ручной ответственности за запас мощности. Managed PostgreSQL проще масштабировать в рамках сервиса, но цена может расти не только из-за CPU и RAM, а ещё из-за дисков, IOPS, хранения копий и сетевого трафика.

Бэкапы, WAL и PITR

Вторая крупная часть TCO — восстановление данных. На VPS команда сама настраивает бэкапы, хранение WAL, снапшоты, PITR и тесты восстановления. В managed-сервисе часть инструментов обычно встроена, но глубина хранения, PITR и дополнительное хранилище зависят от тарифа.

Перед выбором нужно проверить:

• Как часто создаются копии;
• Сколько они хранятся;
• Включён ли PITR и на какой период;
• Где лежат копии;
• Сколько стоит дополнительное хранение;
• Кто отвечает за фактическое восстановление.

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

Мониторинг, администрирование и обновления

PostgreSQL в рабочей среде нужно не только запустить, но и сопровождать. На VPS команда сама собирает метрики, настраивает алерты, следит за логами, обновляет ОС и PostgreSQL, управляет пользователями, правами, параметрами и регламентными проверками.

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

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

HA, SLA, поддержка и инциденты

Отдельный слой TCO — доступность. На VPS репликацию, резервный узел, переключение при отказе, мониторинг и дежурства проектирует команда. SLA провайдера обычно покрывает виртуальную машину, сеть или диски, но не работу PostgreSQL, репликацию и восстановление.

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

• На что именно распространяется SLA;
• Нужен ли резервный узел или Multi-AZ;
• Есть ли автоматическое переключение;
• Какие компенсации и исключения прописаны;
• Какое время реакции у поддержки;
• Как приложение переживает переключение.

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

Как читать TCO без перекоса

TCO не доказывает, что managed-сервис всегда выгоднее. VPS может оставаться дешевле, если нагрузка простая, команда умеет администрировать PostgreSQL и принимает риски. Для разработки, тестирования, раннего MVP или внутреннего инструмента это может быть нормальным выбором.

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

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

Бэкапы, PITR и восстановление: где чаще всего прячется риск

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

«Бэкап есть» и «восстановление проверено» — разные состояния. Первое означает, что где-то лежит копия. Второе — что команда уже проходила сценарий восстановления, знает порядок действий, понимает время простоя и допустимую потерю данных.

Почему обычной ночной копии может быть мало

Типичный пример: в SaaS-сервисе или интернет-магазине кто-то запускает ошибочное DELETE, и часть заказов или клиентских данных исчезает. Вчерашняя копия формально есть, но откат на сутки назад уничтожит новые заказы, платежи и изменения.

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

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

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

Что проверить перед выбором

Перед выбором VPS или managed-сервиса стоит задавать не вопрос «есть ли бэкапы», а вопросы по восстановлению:

• Где физически хранятся копии;
• Как часто они создаются;
• Сколько хранятся;
• Можно ли восстановиться на конкретный момент времени;
• Шифруются ли копии и кто управляет доступом;
• Кто последний раз делал тестовое восстановление;
• Какие RPO и RTO обещаны бизнесу;
• Кто отвечает за восстановление во время инцидента.

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

Если команда не готова регулярно проверять восстановление на VPS, Managed PostgreSQL начинает выглядеть не как переплата, а как способ снизить операционный риск. Но и в managed-сервисе нельзя ограничиваться фразой «автоматические резервные копии включены»: нужно отдельно проверить PITR, срок хранения, регион, стоимость дополнительного хранилища и процедуру восстановления.

Для бизнеса всё это переводится в практичные вопросы: потеряем ли мы заказы, нарушим ли SLA перед клиентами, придётся ли инженеру ночью вручную собирать базу из копий и журналов. 

SLA и HA: договорная доступность не равна магической защите от падений

Бэкапы отвечают на вопрос «как вернуть данные». Но для бизнеса не менее важно, сколько времени продукт будет недоступен, пока команда или провайдер возвращают систему в рабочее состояние. Здесь появляются SLA и высокая доступность — HA.

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

Что на самом деле покрывает SLA

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

В Managed PostgreSQL SLA обычно ближе к сервису базы данных, но и там важно смотреть тариф и условия договора. Высокая доступность может быть отдельной опцией, а не свойством «по умолчанию».

Перед выбором стоит проверить:

• на что именно распространяется SLA;
• нужна ли конфигурация с резервным узлом;
• есть ли автоматическое переключение при отказе;
• какие окна обслуживания и исключения прописаны;
• кто проверяет отказоустойчивость на практике;
• как приложение узнаёт о переключении;
• сколько времени занимает восстановление доступности при типовом сбое.

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

Почему HA — это не просто «вторая машина»

Высокая доступность на VPS не сводится ко второй виртуальной машине. Нужны репликация, резервный узел, автоматическое переключение, защита от split-brain, маршрутизация приложения, мониторинг и регулярные тесты аварий.

Типичный инцидент выглядит так: основная VPS умерла, реплика вроде есть, данные не потеряны, но приложение всё ещё стучится в старый адрес. DNS не обновился, строка подключения не поменялась, команда вручную разбирает, какой узел теперь главный. Формально «копия базы есть», но сервис для клиентов лежит.

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

Но SLA и HA не спасают от всего. Приложение, тяжёлые запросы, неудачные миграции, схема БД и скорость реакции команды всё равно могут сделать продукт недоступным.

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

Контроль и ограничения: где VPS выигрывает у managed-сервиса

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

Это важно, если проекту нужны редкие расширения, конкретные версии модулей, нестандартная схема репликации, особые настройки шифрования, собственный аудит или глубокая интеграция с внутренними системами безопасности. Для типового managed-сервиса такие требования могут быть слишком узкими: провайдер ограничивает список расширений, закрывает часть параметров, не даёт настоящий root-доступ и проводит обслуживание в заданных окнах.

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

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

Но контроль на VPS не бесплатен. Каждое нестандартное решение нужно поддерживать: документировать, обновлять, тестировать после апгрейдов и восстанавливать при сбое. Поэтому вопрос стоит не так: «где больше возможностей?». Правильнее спросить: какие возможности действительно нужны и готова ли команда за них отвечать.

Когда оправдан PostgreSQL на VPS

PostgreSQL на VPS оправдан не только потому, что «дешевле». Низкая стартовая цена — важный аргумент, но для B2B-выбора её нужно рассматривать вместе с контролем, компетенциями команды и ценой простоя.

VPS обычно имеет смысл, если:

• Нужен полный контроль над сервером, ОС, доступами, дисками, сетью и настройками PostgreSQL;
  
• Требуются специфичные расширения, редкие модули, собственные сборки или конкретные версии расширений;
  
• Нужна нестандартная конфигурация: особая репликация, собственные бэкапы, специфичные настройки хранения, аудит или безопасность;
  
• Бюджет ограничен, а цена простоя невысока: разработка, тестирование, ранний MVP, внутренний инструмент или небольшая рабочая нагрузка;
  
• В команде есть компетенции по PostgreSQL: бэкапы, PITR, мониторинг, обновления, репликация и восстановление.

VPS хорош там, где контроль действительно нужен и есть кому за него отвечать. Если аргумент только один — «сервер дешевле в счёте», стоит вернуться к TCO и посчитать часы инженера, бэкапы, мониторинг, обновления, HA, PITR и риски восстановления.

Когда лучше Managed PostgreSQL

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

Managed-сервис обычно рациональнее, если важны:

• SLA и понятная зона ответственности перед платными клиентами;
• Автоматические бэкапы с понятным сроком хранения и процедурой восстановления;
• PITR для отката на момент до ошибки, а не только к последней ночной копии;
• HA, резервный узел и меньше ручных действий при сбое;
• Снижение операционной нагрузки на команду;
• Стандартные версии PostgreSQL, расширения, параметры и лимиты сервиса покрывают требования проекта.

Для зрелого B2B-продукта Managed PostgreSQL часто покупают не ради «удобной панели», а ради снижения операционного риска. Это особенно заметно, когда простой и потеря данных связаны с выручкой, договорными обязательствами, поддержкой клиентов и репутацией.

Рабочее правило простое: VPS оправдан контролем и готовностью эксплуатировать базу самим. Managed PostgreSQL — требованиями к восстановлению, доступности и снижению нагрузки на команду.

Заключение

Выбор между PostgreSQL на VPS и Managed PostgreSQL — это не спор «дешевле или дороже», а решение о границе ответственности. VPS оправдан, когда проекту нужен полный доступ к серверу, специфичные расширения, нестандартная конфигурация и невысокая цена простоя. Но вместе с контролем команда получает бэкапы, обновления, мониторинг, PITR, HA, восстановление и инциденты.

Managed PostgreSQL чаще рациональнее для SaaS, интернет-магазинов, B2B-сервисов с платными клиентами и систем, где потеря данных или долгий простой сразу превращаются в деньги, штрафы или репутационный ущерб. Финальное решение стоит принимать не по цене в прайсе, а по TCO, требованиям RPO/RTO, доступности и способности команды восстановить сервис в реальном инциденте.

FAQ

Managed PostgreSQL полностью снимает администрирование базы с команды?

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

PostgreSQL на VPS всегда дешевле managed-сервиса?

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

Если эти работы регулярны, managed-сервис может оказаться дешевле по полной стоимости владения.

Достаточно ли снапшота VPS для резервного копирования PostgreSQL?

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

Для PITR нужны базовая копия и архивирование WAL.

Когда VPS лучше Managed PostgreSQL?

VPS лучше подходит, если нужны root-доступ, нестандартные настройки ОС, специфичные расширения PostgreSQL или конфигурации, которые managed-провайдер не поддерживает.

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

На что смотреть в SLA managed-базы?

Важно смотреть не только на процент доступности, а на условия: распространяется ли SLA на конкретный тариф, нужен ли резервный узел или Multi-AZ, какие есть окна обслуживания, исключения, компенсации и ограничения.

Отдельно стоит проверить, как работает восстановление и переключение при отказе на практике.

Список источников

1. PostgreSQL Documentation — Continuous Archiving and Point-in-Time Recovery

2. AWS RDS Service Level Agreement

3. AWS RDS Pricing

4. Google SRE Book — Eliminating Toil