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

Возьмём PostgreSQL-базу объёмом 1 ТБ и сравним, во сколько обойдётся её размещение в AWS и на выделенном сервере. Заодно рассмотрим варианты переноса данных и расходы, которые стоит учесть помимо аренды.

• Заполнение диска: в /storage1 занято 1.07 TiB (60% от доступных 1.78 TiB);

• Оперативная память: из 125 GiB RAM задействовано 2% (2.12 GiB);

• Нагрузка на CPU: 16 физических ядер процессора работают с минимальной нагрузкой (Load Average: 0.51).

База в облаке

При развёртывании баз данных в AWS инфраструктуру приходится брать с запасом. Например, под чистый объём данных в 1 ТБ требуется не менее 1,5–2 ТБ дискового пространства, учитывая дополнительное место для индексов, логов, служебных структур и будущего роста.

Предположим, мы планируем разместить PostgreSQL-базу объёмом 1 ТБ в AWS через управляемый сервис Amazon RDS. Под такую задачу выбираем конфигурацию с заделом на производительность и будущий рост:

• Инстанс: db.r7i.4xlarge (16 vCPU, 128 GiB RAM);

• Тип хранилища: General Purpose SSD (gp3);

• Объём диска: 1500 GB;

• Дисковая производительность: 12 000 IOPS и пропускная способность 500 MiB/s (минимальные для нашего типа диска).

Считаем итоговые затраты в официальном калькуляторе AWS для европейского региона. Итоговый чек за содержание такой базы составит $2322 в месяц (калькулятор показывает $28 115 в год, включая разовый авансовый платёж).

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

Однако у Amazon RDS есть одно преимущество: часть задач по обслуживанию базы берёт на себя AWS. На выделенном сервере обновления и резервное копирование нужно настраивать самостоятельно, поэтому при расчёте экономии стоит учитывать и время администратора.

Массовый уход из облака

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

Компания 37signals (разработчик Basecamp и HEY) пользовалась облачными услугами AWS (S3) и Google Cloud больше десяти лет, но в октябре 2022 года решила, что с неё хватит.

Оборудование Dell обошлось примерно в $700 тыс. и, по словам Ханссона, окупилось ещё в 2023 году. Расширять команду девопсов не потребовалось, с серверами справились прежние инженеры. Нужно отметить, что у компании ещё до миграции уже были стойки в дата-центрах и инженеры, то есть переезд обошёлся малой кровью.

У компании Prerender.io серверные расходы снизились на 80%. Сервис подготовки HTML-версий JavaScript-страниц для поисковых роботов тоже перенёс нагрузку с AWS на физические серверы. Технический руководитель оценил годовую экономию примерно в $800 тыс. по сравнению с продолжением работы в AWS.

Масштаб нагрузки объясняет, откуда взялись такие суммы: сервис обрабатывал более 70 тыс. страниц в минуту и хранил около 560 млн страниц. Только передача данных обходилась, по словам команды, в $30–50 тыс. ежемесячно. Первоначально инженеры рассчитывали сократить расходы на 40%, но поэтапный перенос вычислений и кэша позволил добиться вдвое большего результата.

Миграция заняла чуть больше трёх месяцев. Сначала на новую инфраструктуру направили только 1% трафика, затем постепенно переносили вычисления, кэш и данные из RDS. Одновременно меняли архитектуру: часть данных PostgreSQL переносили в Cassandra. Поэтому считать этот кейс чистым сравнением цен облака и железа нельзя.

Почему PostgreSQL, а не MySQL

При масштабировании баз данных до терабайтного уровня выбор СУБД начинает напрямую влиять на требования к железу. PostgreSQL демонстрирует ряд ключевых преимуществ над MySQL именно на крупных объёмах данных. На Хабре много статей, в которых сравнивают эти СУБД, иногда разгораются горячие споры. Вот какие аргументы выдвигают в пользу PostgreSQL:

• Продвинутая параллелизация запросов (Parallel Query): PostgreSQL умеет распараллеливать сканирование B-Tree индексов, соединение таблиц и агрегации по нескольким ядрам CPU. MySQL в аналогичных сценариях выполняет большинство сложных запросов в один поток.

• Гибкая система индексов: основным решением остаётся B-tree, но под конкретные задачи Postgres предлагает GIN (полнотекст, JSONB), GiST (гео, диапазоны) и BRIN (огромные append-only таблицы вроде логов) — аналогов большинству из них в MySQL нет. Плюс частичные индексы: в гигантских базах, где 90% строк — это архив, индекс только по активным записям весит немного, дешевле обходится при записи и помещается в оперативную память.

• Богатые возможности партиционирования (Declarative Partitioning). Секционирование гигантских таблиц по датам или ключам в PostgreSQL позволяет системе мгновенно отсекать ненужные секции на уровне планировщика, что резко сокращает дисковый ввод-вывод. Партиционирование есть и в MySQL, но там ключ секционирования обязан входить во все уникальные индексы, а внешние ключи на таких таблицах не работают. В PostgreSQL этих ограничений нет, плюс секции можно мгновенно подключать и отключать через ATTACH/DETACH PARTITION.

Инструменты миграции

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

Классический дамп

Самый очевидный путь — pg_dump / pg_restore. Он надёжен, требует только сетевого доступа и переживает смену мажорной версии PostgreSQL. Дамп в формате directory умеет работать в несколько потоков, что на больших базах критично.

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

Логическая репликация

Логическая репликация решает проблему простоя. PostgreSQL 10+ умеет реплицировать данные между независимыми кластерами штатными средствами, а RDS это поддерживает — достаточно выставить параметр rds.logical_replication = 1 в parameter group и перезагрузить инстанс. Схему при этом переносим отдельно (pg_dump --schema-only), после чего на источнике создаём публикацию, а на новом сервере — подписку:

-- на RDS
CREATE PUBLICATION migration FOR ALL TABLES;

-- на новом сервере
CREATE SUBSCRIPTION migration
  CONNECTION 'host=mybase.rds.amazonaws.com dbname=mydb user=repl password=***'
  PUBLICATION migration;

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

Недостатки:

• Значения sequence придётся перенести вручную в окне простоя — иначе первый же INSERT на новом сервере упадёт с конфликтом первичного ключа.

• Любые изменения схемы на время миграции нужно заморозить или накатывать руками на обе стороны.

• Таблицы без первичного ключа при FOR ALL TABLES попадают в публикацию автоматически, после чего UPDATE/DELETE по ним падают с ошибкой уже на издателе. Им нужен REPLICA IDENTITY FULL.

AWS Database Migration Service или pglogical

Если встроенная репликация по каким-то причинам не подходит (например, база очень старой версии), можно использовать внешние инструменты. AWS DMS умеет мигрировать данные не только внутрь облака, но и наружу. Альтернативой может стать расширение pglogical, которое работает по похожему с нативной репликацией принципу, но предлагает чуть больше гибкости в фильтрации данных.

Какой сервер нужен для PostgreSQL

Для нашей задачи подойдут спецификации, описанные в начале статьи, в разделе про облачные хранилища:

• CPU: 2×8 ядер;

• RAM: 128 ГБ;

• Диск: SSD 1,5 ТБ.

Размер базы определяет минимальный объём дисков. CPU и RAM выбираются по профилю нагрузки.

Пара слов о том, почему именно так. CPU нагружают активные запросы, фоновые процессы autovacuum и параллельное выполнение, а вот простаивающие соединения расходуют не ядра, а память — при их большом числе спасает пулер вроде PgBouncer. И здесь важный момент: 16 физических ядер и 16 vCPU в облаке — совсем не одно и то же, потому что vCPU обычно означает поток, а не полноценное ядро (обычно 16 vCPU = 8 физических ядер).

Со 128 ГБ памяти весь терабайт, конечно, не закэшируешь, но рабочий набор данных поместится, а значит, база будет реже ходить на диск.

Под такие данные подойдёт один из тарифов на Bare Metal, здесь дискового пространства даже с запасом. Есть тарифы более бюджетные (c HDD), а есть более дорогие (c SSD, которые будут точнее соответствовать инстансу AWS по производительности):

В месяц получается от 27 307 до 37 177 руб. ($333−453), значительно меньше, чем в облаке. Можно выбрать оплату за месяц или за каждый день с автопродлением (без переплат, ровно 1/30 месячной оплаты).

Преимущества Bare Metal:

• 100% ресурсов сервера: без гипервизора, с полным root-доступом и возможностью установить любую операционную систему.

• Сеть до 25 Гбит/с: канал до 1 Гбит/с и 10 ТБ трафика в сутки уже включены. Для конфигураций с сетевыми картами 10G и 25G доступно высокоскоростное подключение до 25 Гбит/с.

• Гибкая дисковая подсистема: диски SATA HDD, SSD и NVMe в различных комбинациях под разные задачи.

• KVM-консоль: при необходимости можно мгновенно получить доступ к экрану и клавиатуре сервера через личный кабинет.

• Tier III и поддержка 24/7: размещение в московском дата-центре и круглосуточная техническая поддержка.

На одной из подходящих конфигураций мы и разместили свою базу на 1 ТБ:

Преимущества своего сервера

Выделенный сервер — это мощная и экономически выгодная альтернатива Amazon RDS для тяжёлых и стабильных нагрузок. В некоторых случаях аренда фиксированного железа обходится значительно дешевле облачных инстансов аналогичной конфигурации, избавляя от астрономических переплат за IOPS и скрытых платежей.

В нашем расчёте аренда выделенного сервера обходится в 27–37 тыс. рублей в месяц ($333−453) против 2322 долларов для Amazon RDS. В зависимости от выбранной конфигурации экономия на аренде инфраструктуры составляет примерно пять–семь раз.

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

© 2026 ООО «МТ ФИНАНС»