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

MAATRIX

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

Что нужно перед установкой

Для старта подойдёт скромный VPS: 1–2 ядра, 2 ГБ RAM и SSD-диск. Этого хватает под небольшой проект, API или бэкенд с десятками одновременных подключений. Если планируете аналитику, тяжёлые запросы или сотни клиентов — берите 4 ГБ RAM и выше, память здесь важнее всего.

Определитесь с локацией заранее. Если основная аудитория в России — берите RU-сервер, чтобы пинг до приложения был минимальным, а персональные данные хранились в стране согласно 152-ФЗ. Если база обслуживает зарубежный сервис или интегрируется с иностранными API — логичнее US или UK.

В примерах используется Ubuntu 24.04 LTS с доступом по SSH-ключу под пользователем с правами sudo. Все команды выполняются от обычного пользователя с sudo, работать под root напрямую не рекомендуется.

Установка PostgreSQL из репозитория PGDG

В стандартных репозиториях Ubuntu лежит не самая свежая версия PostgreSQL. Чтобы получить актуальный релиз и оперативные обновления безопасности, подключите официальный репозиторий проекта — PGDG.

sudo apt update && sudo apt install -y curl ca-certificates
sudo install -d /usr/share/postgresql-common/pgdg
sudo curl -o /usr/share/postgresql-common/pgdg/apt.postgresql.org.asc \
  https://www.postgresql.org/media/keys/ACCC4CF8.asc
. /etc/os-release
echo "deb [signed-by=/usr/share/postgresql-common/pgdg/apt.postgresql.org.asc] \
  https://apt.postgresql.org/pub/repos/apt $VERSION_CODENAME-pgdg main" | \
  sudo tee /etc/apt/sources.list.d/pgdg.list
sudo apt update
sudo apt install -y postgresql-17

После установки служба запускается автоматически. Проверьте состояние и версию:

sudo systemctl status postgresql
sudo -u postgres psql -c "SELECT version();"

Если видите строку с версией PostgreSQL 17 — сервер работает. Данные по умолчанию лежат в /var/lib/postgresql/17/main, конфиги — в /etc/postgresql/17/main. Разделение конфигов и данных по каталогам — особенность пакета от PGDG в Debian и Ubuntu: это удобно, потому что вы можете держать несколько версий и кластеров на одной машине и переключаться между ними без конфликтов.

Стоит сразу понять логику службы. PostgreSQL управляется через systemd, но за конкретный кластер отвечает обёртка pg_ctlcluster. Команда pg_lsclusters покажет все установленные кластеры, их версии, порты и статус. Это пригодится позже, когда будете обновлять мажорную версию или переносить данные — вы всегда видите полную картину, а не гадаете, какой процесс какой базе принадлежит.

Создание роли и базы данных

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

sudo -u postgres psql

В консоли psql выполните:

CREATE ROLE appuser WITH LOGIN PASSWORD 'слоЖный_Пароль_2026';
CREATE DATABASE appdb OWNER appuser;
GRANT ALL PRIVILEGES ON DATABASE appdb TO appuser;
\q

Проверьте вход новой ролью локально:

psql -h 127.0.0.1 -U appuser -d appdb -W

Правило простое: одно приложение — одна роль и одна база. Так вы ограничиваете область поражения при утечке пароля и не путаете данные разных проектов.

Отдельно про права. В PostgreSQL 15 и новее роль, не являющаяся владельцем базы, по умолчанию не может создавать таблицы в схеме public — это изменение застаёт врасплох многих, кто привык к старому поведению. Если приложение жалуется на отказ в создании таблиц, выдайте роли права на схему явно: подключитесь к базе под владельцем и выполните GRANT ALL ON SCHEMA public TO appuser. Ещё лучше — заведите под приложение отдельную схему и работайте в ней, оставив public пустой. Так вы получаете чистое разделение и меньше сюрпризов при миграциях.

Настройка сетевого доступа

По умолчанию PostgreSQL слушает только localhost, и это правильно с точки зрения безопасности. Если база и приложение на одном сервере — ничего менять не нужно. Открывать порт наружу стоит только тогда, когда к базе подключается внешний клиент.

Откройте postgresql.conf и разрешите слушать нужный адрес:

sudo nano /etc/postgresql/17/main/postgresql.conf

listen_addresses = 'localhost,10.0.0.5'

Затем в pg_hba.conf задайте, кому и как разрешён вход. Никогда не открывайте 0.0.0.0/0 без шифрования — это прямой путь к взлому.

sudo nano /etc/postgresql/17/main/pg_hba.conf

# TYPE  DATABASE  USER      ADDRESS         METHOD
host    appdb     appuser   10.0.0.0/24     scram-sha-256

Перезапустите сервер и обязательно закройте порт 5432 фаерволом для всех, кроме доверенных адресов:

sudo systemctl restart postgresql
sudo ufw allow from 10.0.0.0/24 to any port 5432 proto tcp

Самый безопасный вариант доступа снаружи — не открывать порт вообще, а подключаться через SSH-туннель или частную сеть между серверами. SSH-туннель поднимается одной командой с клиента: ssh -L 5432:localhost:5432 user@ваш-сервер, после чего приложение обращается к localhost:5432, а весь трафик идёт по шифрованному каналу. Никаких открытых портов, никакого перебора паролей ботами по 5432 — а такие сканирования идут по всему интернету непрерывно, и открытый порт БД находят за часы.

Если серверов несколько и они общаются постоянно, разумнее объединить их приватной сетью или VPN-туннелем (например, WireGuard) и слушать только на внутреннем адресе. Тогда база физически недоступна из публичного интернета, а между вашими машинами трафик идёт напрямую и быстро.

Базовый тюнинг под вашу память

Настройки по умолчанию рассчитаны на слабое железо и не используют ресурсы VPS. Несколько параметров дают заметный прирост. Ориентиры для сервера с 4 ГБ RAM:

shared_buffers = 1GB
effective_cache_size = 3GB
work_mem = 32MB
maintenance_work_mem = 256MB
max_connections = 100

shared_buffers — примерно четверть RAM, это основной кэш. effective_cache_size — оценка доступной памяти под кэш, около 75% RAM. work_mem умножается на число операций сортировки, поэтому не задирайте его слишком высоко при большом числе подключений. Если соединений много и они короткие, поставьте перед базой пул-менеджер вроде pgBouncer вместо роста max_connections.

После правки перезапустите сервер и проверьте, что он поднялся без ошибок в журнале:

sudo systemctl restart postgresql
sudo journalctl -u postgresql -n 20

Резервное копирование

База без бэкапа — это вопрос времени до потери данных. Для одной базы достаточно логического дампа через pg_dump, для всего кластера — pg_dumpall.

sudo -u postgres pg_dump -Fc appdb > /var/backups/appdb_$(date +%F).dump

Формат -Fc (custom) сжат и позволяет восстанавливать выборочно. Восстановление:

pg_restore -d appdb -U appuser --clean /var/backups/appdb_2026-08-24.dump

Автоматизируйте задачу через cron — например, ежедневно в 3 часа ночи с хранением дампов за две недели:

0 3 * * * postgres pg_dump -Fc appdb > /var/backups/appdb_$(date +\%F).dump

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

Обслуживание и безопасность

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

Меняйте пароли ролей на длинные и уникальные, используйте метод scram-sha-256 вместо устаревшего md5. Логи запросов помогают найти узкие места — включите log_min_duration_statement = 1000, чтобы видеть все запросы дольше секунды.

Чтобы всё это работало стабильно, нужен сервер с гарантированными ресурсами и root-доступом. В MAATRIX можно арендовать VPS в России, США или Великобритании под PostgreSQL за пару минут, а оплатить картой российского банка, по СБП, криптовалютой или токеном MAAT — иностранная карта не нужна.

Частые вопросы