Самостоятельное размещение PostgreSQL на VPS: Избегайте цен на управляемые базы данных

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

Экспорт снимка, о котором ты забыл. Плата за выход из тестовой среды, который был запущен в прошлый вторник через ‘pg_dump’.

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

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

Разрыв между «Postgres за 25 долларов в месяц» и тем, что отображается на карте, стал значительным, и 4 ГБ VPS по цене одного дополнения 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 ГБ RAM, ~100 ГБ данных, низкая до умеренной интенсивность записи, один регион), цены по состоянию на май 2026 года:

Опция	Вычисления	Хранилище	Эгресс сверх бесплатного тарифа	Лучше всего подходит для
Самостоятельное размещение на VPS с 4 GB	Фиксированная цена тарифа	Обычно включено	Обычно без ограничений или с высоким лимитом	Стабильные рабочие нагрузки, команды, ориентированные на экономию и знакомые с 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 failover) и стоимость вычислений примерно удваивается, поднимая производственную конфигурацию до $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 ГБ RAM с хранением на NVMe. Большие наборы данных, интенсивные одновременные подключения или аналитические задачи увеличивают требования до 8 ГБ или 16 ГБ и выше.

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

Общие рекомендации по настройке сервера PostgreSQL начинаются с:

• shared_buffers примерно 25% от системной RAM.
• effective_cache_size примерно 50%-75% от системной RAM.
• work_mem устанавливайте с учетом сложности одновременных запросов, а не только общего объема RAM.

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

Карта планов и нагрузок, которую тебе нужно знать:

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

Тарифы DreamHost для VPS Hosting предоставляют тебе доступ к Root, хранилище NVMe и неограниченную пропускную способность с предсказуемым месячным счетом.

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

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

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

1. Настройка VPS: Выбери тариф с достаточным объемом RAM для твоей рабочей среды (базовый уровень — Stack 4/4 GB). Рекомендуемая ОС — 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 Job. Пользовательский формат хорошо сжимается и, наряду с форматом директории, поддерживает параллельные и выборочные опции восстановления в pg_restore. Отправь дамп в объектное хранилище вне VPS (DreamObjects, совместимые с S3).

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

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

Механизм	Что Он Даёт	Стоимость
pg_dump + cron + хранилище вне VPS	Ежедневное логическое резервное копирование, переносимое	Задержка восстановления, не точка во времени
pg_basebackup + архивация WAL	Физическое резервное копирование с возможностью восстановления по точке во времени	Сложность хранения и операций
Потоковая репликация	Горячая резервная копия, почти нулевой Recovery Point Objective (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, но аутентификация, хранение данных и периферийные слои Supabase не мигрируют. Схема вашего приложения мигрирует. Замените эти слои на самостоятельно размещенные аналоги перед переходом.
3. Из Neon: Ветвление исчезает после миграции; планируйте резервное копирование вместо этого. Процесс дампа и восстановления прост, но операционные привычки, такие как мгновенное ветвление, требуют замены рабочего процесса.

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

Когда Стоит Добавить PgBouncer или Остаться на Vanilla Postgres?

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

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

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

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

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

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

Да, ты узнаешь, когда это будет нужно.

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

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

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

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

Часто Задаваемые Вопросы О PostgreSQL На VPS

Сколько RAM требуется PostgreSQL на VPS?

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

Могу ли я запустить PostgreSQL на VPS с 2 ГБ?

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

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

Да, самостоятельное хостинг PostgreSQL на VPS дешевле, чем RDS или Supabase для большинства стабильных рабочих нагрузок. 4 GB VPS обычно стоит долю от эквивалентной спецификации RDS, Supabase Pro или Neon Scale, когда суммируются затраты на хранение, резервное копирование и исходящий трафик. Но при этом управление базой данных лежит на тебе.

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

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

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

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

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

Запускай pg_dump —format=custom по расписанию ежедневного Cron Job и сохраняй результат вне VPS в совместимом с S3 объектном хранилище. Используй pg_basebackup вместе с архивацией WAL для восстановления по точкам во времени, когда важна потеря данных в секундах. Тестируй восстановление ежемесячно.

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

Тарифный план VPS Stack 4 от DreamHost (4 GB RAM) является рекомендуемой базой для большинства баз данных производственных приложений. Выбери Stack 8 (8 GB) для больших наборов данных или высокой конкурентности, и Stack 16 для Postgres вместе с другими ресурсоемкими сервисами.

Стоит ли использовать PgBouncer с PostgreSQL на малом VPS?

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