PostgreSQL на VPS: как уйти от дорогих managed-баз данных

Вычисления. Хранилище. Срок хранения резервных копий.

Экспорт снимка, о котором вы забыли. Плата за исходящий трафик из staging-среды, где во вторник запустили 'pg_dump'.

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

Но, чёрт возьми.

Разрыв между "Postgres за 25 долларов в месяц" и тем, что в итоге списывается с карты, стал огромным, и VPS с 4 ГБ по цене одного дополнения Supabase теперь запускает всю вашу базу данных с запасом для кэширования горячих страниц операционной системой.

Самостоятельный хостинг производственной базы Postgres больше не является той операционной проблемой, какой был раньше. Репозиторий PostgreSQL Global Development Group (PGDG) надёжен; современные установки PostgreSQL (v14+) по умолчанию используют шифрование паролей SCRAM-SHA-256, а устаревший MD5 официально объявлен устаревшим с v18. Причины, по которым люди остаются на RDS, Supabase или Neon сегодня, являются операционными, а не техническими.

Мы говорим о реальных счетах, реальных операционных затратах и о том, как на самом деле выглядит современный хостинг Postgres.

Сколько на самом деле стоит самостоятельный хостинг PostgreSQL на VPS?

Самостоятельно размещённый PostgreSQL на VPS с 4 ГБ ОЗУ обычно обходится в долю от стоимости эквивалентного RDS, Supabase Pro или Neon Scale, когда в управляемый счёт включаются хранилище, резервное копирование и исходящий трафик.

PostgreSQL — база данных, которую используют 55,6% разработчиков, согласно опросу разработчиков Stack Overflow за 2025 год, и она является самой популярной два года подряд. Это также база данных, которую вы можете комфортно запускать самостоятельно.

Сравнение для типичной рабочей нагрузки небольшой команды (4 ГБ ОЗУ, ~100 ГБ данных, низкая или умеренная нагрузка на запись, один регион), цены указаны на май 2026 года:

Вариант	Вычисления	Хранилище	Исходящий трафик сверх бесплатного лимита	Лучше всего подходит для
Самостоятельный хостинг на VPS с 4 ГБ	Фиксированная цена плана	Обычно включено	Обычно безлимитный или с большим лимитом	Стабильные рабочие нагрузки, команды, чувствительные к затратам и умеющие работать с Linux
AWS RDS db.t4g.medium	$47,45/мес. только вычисления	~$0,115/ГБ-мес. gp3	~$0,09/ГБ интернет/вне региона	Команды, которым нужны управляемые резервные копии, отказоустойчивость и нативные возможности AWS
Supabase Pro	$25/мес. базовая ставка + использование	$0,125/ГБ диска базы данных сверх включённых 8 ГБ	$0,09/ГБ сверх 250 ГБ	Приложения, которым нужны Postgres, аутентификация, хранилище и реальное время в одном стеке
Neon Scale	$0,222 за CU/час	$0,35 за ГБ/мес.	По счётчику использования	Разработка с неравномерной нагрузкой, частыми предпросмотрами и ветвлениями

Цена RDS db.t4g.medium по требованию составляет примерно $0,065 в час, или около $47,45 в месяц только за вычисления.

Добавьте 100 ГБ хранилища gp3 по примерно $0,115/ГБ-мес. и автоматические резервные копии, и однозонная конфигурация будет стоить около $60/мес. Включите Multi-AZ отказоустойчивость, и стоимость вычислений примерно удвоится, доведя производственную конфигурацию до $100/мес. и выше.

Это немаленький разрыв.

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

Когда имеет смысл самостоятельный хостинг PostgreSQL?

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

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

Решение определяют три фактора: стоимость, конфиденциальность и суверенитет данных, а также контроль.

Где самостоятельный хостинг явно выигрывает:

• Стабильный трафик в одном регионе с предсказуемым рабочим набором.
• Небольшие и средние SaaS-приложения с одной базой данных Postgres и командой, знакомой с Linux.
• Нагрузки, чувствительные к конфиденциальности, где база данных не должна находиться в чужой аренде.
• Команды, заботящиеся о затратах, чей управляемый счёт превысил порог операционных неудобств.

Где управляемый хостинг явно выигрывает:

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

Цифра экономии в 40–60% часто упоминается. Относитесь к ней с осторожностью.

По состоянию на 2021 год автор AWS Рупеш Десаи задокументировал, что PostgreSQL на EC2 обходится на 40–60% дешевле, чем RDS при эквивалентных характеристиках, что старше большинства текущих семейств инстансов RDS.

Текущая версия — это анализ стоимости от byteiota, опубликованный в конце 2025 года, который утверждает, что RDS на 75–88% дороже, чем эквивалентное выделенное оборудование.

Честная точка безубыточности — это операционные часы, а не стоимость сервера.

Как выбрать правильный размер VPS для PostgreSQL?

Большинство производственных баз данных приложений комфортно работают на 4 ГБ ОЗУ с NVMe-хранилищем. Более крупные наборы данных, большое количество одновременных подключений или аналитические нагрузки увеличивают требования до 8 ГБ, 16 ГБ и выше.

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

Типичные рекомендации по настройке PostgreSQL начинаются с:

• shared_buffers примерно 25% от системной ОЗУ.
• effective_cache_size примерно 50–75% от системной ОЗУ.
• work_mem задаётся консервативно — исходя из сложности одновременных запросов, а не только общего объёма ОЗУ.

На VPS с 4 ГБ это обычно означает выделение около 1 ГБ для shared_buffers, оставляя достаточно памяти для кэша страниц Linux, чтобы хранить часто используемые данные. Этот баланс отчасти объясняет, почему скромный сервер на 4 ГБ может комфортно запускать множество небольших и средних производственных нагрузок.

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

Уровень ОЗУ	Типичная нагрузка	Рекомендуемый план стека
2 ГБ	Среды разработки, низкотрафиковые побочные проекты	Ниже базового уровня
4 ГБ	Большинство производственных баз данных приложений	Стек 4
8 ГБ	Более крупные наборы данных, больше одновременных подключений	Стек 8
16 ГБ+	Postgres вместе с другими тяжелыми сервисами, аналитика	Стек 16

VPS-хостинг DreamHost предоставляет root-доступ, хранилище NVMe и безлимитный трафик по предсказуемому ежемесячному счету.

Это четыре вещи, от которых зависит самостоятельная нагрузка на Postgres.

Как установить PostgreSQL на VPS?

Вы устанавливаете PostgreSQL на VPS за пять сжатых шагов.

1. Подготовка VPS: Выберите тариф с достаточным объемом ОЗУ для вашего рабочего набора (Stack 4/4 ГБ — базовый уровень). Рекомендуемая ОС — Ubuntu 24.04 LTS. Подключайтесь по SSH с аутентификацией по ключу, а не по паролю.
2. Установка из официального репозитория PGDG: Дистрибутивная ‘apt install postgresql’ отстает от основных версий. Добавьте репозиторий PGDG apt, затем выполните ‘sudo apt install postgresql-18.’ Подтвердите командой ‘sudo systemctl status postgresql’
3. Установка пароля postgres и создание роли приложения: Выполните sudo -i -u postgres, затем psql, затем password postgres. Создайте выделенную роль с минимальными привилегиями: ‘CREATE ROLE myapp WITH LOGIN PASSWORD '...';’ и ‘CREATE DATABASE myapp_prod OWNER myapp;’
4. Правильная привязка слушателя: Откройте /etc/postgresql/18/main/postgresql.conf. Установите listen_addresses = ‘localhost’, если приложение и база данных находятся на одной машине, или привяжите к частному IP, если приложение работает на отдельном VPS. Избегайте привязки PostgreSQL к 0.0.0.0 на публично доступном интерфейсе. Открытые экземпляры PostgreSQL агрессивно сканируются и взламываются автоматическими ботами.
5. Защита ‘pg_hba.conf’ и UFW: Отредактируйте pg_hba.conf, чтобы разрешить только те IP-адреса приложений, которые вам действительно нужны, с методом аутентификации ‘scram-sha-256’. Настройте UFW, чтобы разрешить порт 5432 только с тех же IP-адресов. Используйте SSH-туннель для инструментов администрирования (и, пожалуйста, не открывайте порт 5432 для публичного интернета).

Попробуйте это с другой машины: psql -h <vps-ip> -U postgres.

Тайм-аут или отклоненное соединение с неавторизованного IP обычно означает, что ваш слушатель и правила брандмауэра работают как надо. Запрос пароля из публичного интернета означает, что что-то настроено неправильно. Как только Postgres запущен, настройка — только половина дела.

Как защитить PostgreSQL на VPS?

PostgreSQL на VPS защищается на трех уровнях, плюс гигиена ролей и периодичность обновлений.

1. Аутентификация: Используйте scram-sha-256 для новых установок и удалите устаревшие правила md5 из pg_hba.conf. Документация PostgreSQL теперь предупреждает, что поддержка паролей, зашифрованных MD5, устарела и будет удалена в будущем выпуске.
2. Сеть: Привяжите PostgreSQL к ‘localhost’, частному IP или интерфейсу, доступному только с ваших серверов приложений. Избегайте привязки к публично доступному интерфейсу. Поверх настройте UFW и разрешите порт 5432 только с доверенных IP приложений.
3. Шифрование при передаче: Включите TLS для любого соединения, пересекающего границу сети. Установите ssl = on в postgresql.conf, затем используйте правила hostssl … scram-sha-256 в pg_hba.conf, чтобы клиенты не могли незаметно вернуться к соединениям без TLS. Самоподписанные сертификаты приемлемы для внутреннего трафика, если клиенты правильно их проверяют.
4. Роли: Подключения приложений должны использовать роль с минимальными привилегиями, имеющую только права, необходимые для схем этого приложения. Суперпользователь предназначен для миграций и аварийных ситуаций.
5. Обновления: Используйте репозиторий PGDG apt для актуальных пакетов PostgreSQL. Включите автоматические обновления безопасности для ОС, но обновления PostgreSQL планируйте обдуманно, чтобы внезапная перезагрузка не стала вашим инцидентом недели. 

Ваш контрольный список безопасности:

• Используйте только scram-sha-256; отключите md5.
• Привяжите ‘listen_addresses’ к localhost или частному IP.
• Правила UFW разрешают порт 5432 только с доверенных IP.
• SSL/TLS включен для любых соединений, пересекающих сеть.
• Приложение подключается как роль с минимальными привилегиями, никогда как ‘postgres’.
• Автоматические обновления безопасности включены.
• Никаких строк ‘host all all 0.0.0.0/0 md5’ в ‘pg_hba.conf’ никогда.

Последний пункт — это предостережение.

Публичный порт 5432 со слабыми учетными данными — известная цель для криптомайнеров и атак перебором. Открытые экземпляры PostgreSQL постоянно сканируются автоматическими ботами в поисках учетных записей по умолчанию, утекших паролей или разрешительных правил pg_hba.conf.

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

Как выполнять резервное копирование и репликацию PostgreSQL на VPS?

Резервное копирование PostgreSQL на VPS использует один из трех механизмов, выбранных в зависимости от сбоя, от которого вы защищаетесь. Логические резервные копии через pg_dump для переносимости, физические резервные копии через pg_basebackup плюс архивирование WAL для восстановления на момент времени, и потоковая репликация для высокой доступности.

Логические резервные копии обрабатывают миграции, частичные восстановления и обновления разработки. Запускайте pg_dump --format=custom --file=mydb.dump mydb_prod из ежедневного cron-задания. Пользовательский формат хорошо сжимается и, наряду с форматом каталога, поддерживает параллельное и выборочное восстановление pg_restore. Отправьте дамп во внешнее объектное хранилище (DreamObjects, совместимое с S3).

Физические резервные копии обрабатывают восстановление всей системы и восстановление на момент времени. pg_basebackup плюс непрерывное архивирование журнала упреждающей записи (WAL) позволяет восстановиться до любого момента между последней базовой резервной копией и самым последним сегментом WAL — это вариант производственного уровня, когда допустимая потеря данных измеряется секундами, а не часами.

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

Механизм	Что он вам дает	Что это стоит
pg_dump + cron + внешнее хранилище VPS	Ежедневное логическое резервное копирование, переносимое	Задержка восстановления, не восстановление на момент времени
pg_basebackup + архивирование WAL	Физическая резервная копия с восстановлением на момент времени	Хранение и эксплуатационная сложность
Потоковая репликация	Горячий резерв, почти нулевая целевая точка восстановления (RPO), масштабирование чтения	Второй VPS плюс управление репликацией

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

Как мигрировать с RDS, Supabase или Neon на VPS?

Вы мигрируете с управляемого провайдера Postgres на VPS за четыре шага.

1. Подготовьте целевой VPS: точно совпадайте с мажорной версией Postgres источника. Установите PostgreSQL на новом VPS, следуя шагам выше, затем заранее создайте роль приложения и базу данных.
2. Сделайте дамп из источника: Выполните pg_dump --format=custom --no-owner --no-privileges --file=src.dump <source-connection-string>. Флаги --no-owner и --no-privileges удаляют специфичные для провайдера назначения роли, которые редко корректно воссоздаются на новом хосте.
3. Восстановите на целевой сервер: Выполните pg_restore --dbname=myapp_prod --jobs=4 --no-owner --no-privileges src.dump. Следите за предупреждениями о расширениях. RDS, Supabase и Neon часто включают расширения, которые могут отсутствовать в ванильном Postgres. Установите совместимые расширения из пакетов PGDG или postgresql-contrib перед восстановлением.
4. Смена строки подключения и проверка: Сначала укажите стейджинг-окружению новый VPS, запустите свой набор тестов, затем проверьте репрезентативные производственные запросы и потоки приложения, прежде чем переключать строку подключения для продакшена. Для приложений с низкой частотой записи короткое окно обслуживания во время окончательного переключения часто проще, чем настройка репликации. Оставьте исходную базу данных онлайн и доступной только для чтения в течение нескольких дней в качестве цели для отката.

Что меняется в зависимости от провайдера?

1. Из RDS: Специфичные для RDS роли (‘rds_superuser’, ‘rdsadmin’) не существуют в ванильном Postgres; флаги --no-owner и --no-privileges справляются с этим. Некоторые управляемые расширения RDS требуют ручной установки, а исходящий трафик из AWS во время дампа оплачивается отдельно.
2. Из Supabase: Postgres — это настоящий Postgres, но уровни аутентификации, хранения и edge-функций Supabase не мигрируют. Ваша схема приложения — мигрирует. Замените эти уровни на самостоятельно размещённые эквиваленты перед переключением.
3. Из Neon: Ветвление исчезает после миграции; вместо него планируйте резервное копирование. Дамп и восстановление просты, но операционные привычки, такие как мгновенные ветки, требуют замены рабочего процесса.

Сама миграция обычно занимает меньше времени, чем выбор тарифного плана VPS. Реалистичное время простоя — минуты для небольших баз данных, дольше при воспроизведении WAL для крупных. Большинство установок останавливаются здесь, но есть один сценарий, который заставляет вас двигаться дальше…

Когда стоит добавить PgBouncer или остаться на ванильном Postgres?

Большинству приложений на VPS с 4 ГБ ОЗУ вначале не нужен пул соединений. Добавьте PgBouncer, когда количество одновременных подключений превысит примерно 100, или ваш стек приложений открывает новое соединение на каждый запрос.

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

Имеют значение два режима пулинга:

• Пулинг сессий (Session pooling): Каждый клиент получает одно серверное соединение на время сессии. Безопасно для любого приложения, без изменения семантики, меньший прирост пропускной способности.
• Пулинг транзакций (Transaction pooling): Каждый клиент получает серверное соединение на время одной транзакции. Большой прирост пропускной способности. Вы теряете функции, зависящие от состояния сессии (подготовленные запросы, консультативные блокировки, ‘LISTEN’/’NOTIFY’), если только приложение не написано с учётом этого.

Большинству небольших SaaS-приложений с ORM, использующим пул соединений, PgBouncer не нужен, пока не понадобится. Сигналом о том, что вы пересекли черту, являются ошибки ‘FATAL: too many connections’ или нехватка памяти из-за неактивных соединений.

Установите его с помощью sudo apt install pgbouncer, настройте /etc/pgbouncer/pgbouncer.ini со своим списком баз данных и режимом пула, затем укажите приложению на PgBouncer порт 6432.

Да, вы поймёте, когда он понадобится.

Принятие окончательного решения

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

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

В любом случае, сделайте глубокий вдох, прежде чем открыть следующий счёт.

Часто задаваемые вопросы о PostgreSQL на VPS

Сколько оперативной памяти нужно PostgreSQL на VPS?

PostgreSQL работает на 1–2 ГБ для небольших нагрузок и комфортно на 4 ГБ для большинства рабочих баз данных приложений. Более тяжёлые наборы данных, большее количество одновременных подключений или аналитические нагрузки увеличивают требования до 8 ГБ и более.

Можно ли запустить PostgreSQL на VPS с 2 ГБ ОЗУ?

Да, вы можете запустить PostgreSQL на VPS с 2 ГБ ОЗУ для небольших приложений, сред разработки и низконагруженных побочных проектов. 2 ГБ оставляют мало запаса для кэширования, поэтому производительность запросов падает по мере того, как данные перерастают объём памяти. Для рабочих нагрузок 4 ГБ — более безопасный базовый уровень.

Дешевле ли самостоятельное размещение PostgreSQL на VPS, чем RDS или Supabase?

Да, самостоятельное размещение PostgreSQL на VPS дешевле, чем RDS или Supabase для большинства стабильных рабочих нагрузок. VPS с 4 ГБ ОЗУ обычно обходится в долю стоимости аналогичного RDS, Supabase Pro или Neon Scale, если учесть хранилище, резервное копирование и исходящий трафик. Оборотная сторона — вы сами управляете базой данных.

Как безопасно открыть доступ к PostgreSQL на VPS?

Не открывайте порт 5432 для публичного интернета. Привяжите PostgreSQL к localhost или частному IP, используйте аутентификацию scram-sha-256, а для инструментов администрирования используйте SSH-туннели вместо открытия порта 5432 для вашего ноутбука. Публичный порт 5432 со слабой аутентификацией — известная цель для криптомайнеров.

Нужно ли использовать Docker для PostgreSQL на VPS?

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

Как создать резервную копию PostgreSQL на VPS?

Выполняйте pg_dump --format=custom по ежедневному расписанию cron и сохраняйте результат вне VPS в S3-совместимое объектное хранилище. Используйте pg_basebackup с архивированием WAL для восстановления на момент времени, когда важны секунды потери данных. Ежемесячно тестируйте восстановление.

Какой тарифный план выбрать для самостоятельного размещения PostgreSQL на DreamHost?

План VPS Stack 4 DreamHost (4 ГБ ОЗУ) рекомендуется в качестве базового уровня для большинства рабочих баз данных приложений. Выберите Stack 8 (8 ГБ) для больших наборов данных или высокой степени параллелизма, и Stack 16 для Postgres вместе с другими ресурсоёмкими сервисами.

Нужно ли использовать PgBouncer с PostgreSQL на небольшом VPS?

Большинству приложений на VPS с 4 ГБ ОЗУ вначале не нужен PgBouncer. Добавляйте пул соединений, когда количество одновременных подключений приближается к 100, или когда ваше приложение открывает новое соединение на каждый запрос.