Как установить PostgreSQL на VPS с Ubuntu или Debian

Шаг 1. Установите PostgreSQL из репозитория дистрибутива

Пакет postgresql из репозитория Ubuntu или Debian - самый простой путь: он сам создаёт кластер базы, системного пользователя postgres и сервис, который запускается при загрузке. Обновления безопасности приходят вместе с обычным apt upgrade:

sudo apt update
sudo apt install -y postgresql
sudo systemctl status postgresql
sudo -u postgres psql -c "SELECT version();"

Если нужна версия новее, чем в дистрибутиве, подключите официальный репозиторий PostgreSQL по инструкции на postgresql.org - остальные шаги не меняются. Файлы настроек лежат в /etc/postgresql/<версия>/main/.

Шаг 2. Создайте роль и базу для приложения

Роль в PostgreSQL - это пользователь базы данных. Приложению нужна своя роль с паролем и своя база, а не суперпользователь postgres. createuser --pwprompt спросит пароль, createdb --owner создаст базу, которой владеет эта роль:

sudo -u postgres createuser --pwprompt myapp
sudo -u postgres createdb --owner=myapp myapp
psql -h localhost -U myapp -d myapp -c "SELECT current_user;"

То же самое можно сделать SQL-командами в консоли psql. Команда sudo -u postgres psql пускает без пароля благодаря методу peer: PostgreSQL сверяет имя роли с именем системного пользователя при подключении через локальный сокет.

sudo -u postgres psql
CREATE ROLE myapp WITH LOGIN PASSWORD 'strong-password';
CREATE DATABASE myapp OWNER myapp;
\q

Шаг 3. Подключайтесь удалённо через SSH-туннель

SSH-туннель - самый безопасный способ открыть базу в DBeaver, pgAdmin или DataGrip со своего компьютера: порт 5432 остаётся закрытым, а трафик идёт внутри уже защищённого SSH-соединения. Выполните команду на своём компьютере, подставив пользователя и IP сервера, и не закрывайте окно:

ssh -N -L 5432:localhost:5432 deploy@203.0.113.10

Теперь в клиенте подключайтесь к localhost:5432 с ролью myapp и её паролем. Если на компьютере уже работает свой PostgreSQL, возьмите другой локальный порт: -L 15432:localhost:5432. Как настроить вход по ключу - в статье про подключение к VPS по SSH.

Шаг 4. Если порт всё же нужно открыть

Прямой доступ к порту 5432 нужен, когда к базе ходит другой сервер, а туннель держать неудобно. Тогда закрывают всё, кроме одного адреса, - на трёх уровнях: PostgreSQL слушает внешний интерфейс, pg_hba.conf пускает только нужную роль с нужного IP, UFW пропускает пакеты только с этого IP. Сначала узнайте пути к файлам настроек:

sudo -u postgres psql -c "SHOW config_file;"
sudo -u postgres psql -c "SHOW hba_file;"

Измените listen_addresses в postgresql.conf и добавьте строку в pg_hba.conf, подставив IP своего клиента вместо 198.51.100.7. hostssl разрешает только шифрованные подключения - на Ubuntu и Debian SSL в PostgreSQL включён по умолчанию с самоподписанным сертификатом, а scram-sha-256 - современный метод проверки пароля:

# postgresql.conf
listen_addresses = '*'

# pg_hba.conf - строка в конец файла
hostssl  myapp  myapp  198.51.100.7/32  scram-sha-256

sudo systemctl restart postgresql
sudo ufw allow from 198.51.100.7 to any port 5432 proto tcp
sudo ss -tlnp | grep 5432

Шаг 5. Настройте резервные копии pg_dump

pg_dump -Fc делает согласованный дамп базы в сжатом формате custom прямо на работающем сервере - останавливать PostgreSQL не нужно. Роли и их пароли в дамп базы не входят, их сохраняет pg_dumpall --globals-only:

mkdir -p ~/backups
sudo -u postgres pg_dump -Fc myapp > ~/backups/myapp-$(date +%F).dump
sudo -u postgres pg_dumpall --globals-only > ~/backups/globals-$(date +%F).sql

Восстанавливают дамп командой pg_restore - для проверки удобно разворачивать его в отдельную базу, не трогая рабочую:

sudo -u postgres createdb --owner=myapp myapp_restored
sudo -u postgres pg_restore -d myapp_restored --no-owner --role=myapp < ~/backups/myapp-2026-10-05.dump

Дамп, который лежит на том же сервере, пропадёт вместе с ним. Как отправлять дампы на другой сервер по расписанию, хранить историю и проверять восстановление - в статье про резервные копии VPS.

Шаг 6. Базовая настройка памяти

По умолчанию PostgreSQL берёт под свой кеш (shared_buffers) всего 128 МБ. Общепринятый ориентир - около 25% оперативной памяти сервера, а effective_cache_size - подсказка планировщику, сколько данных поместится в кеше вместе с кешем ОС, обычно 50-75% памяти. Пример для сервера с 4 ГБ, где PostgreSQL - основная нагрузка:

sudo -u postgres psql -c "ALTER SYSTEM SET shared_buffers = '1GB';"
sudo -u postgres psql -c "ALTER SYSTEM SET effective_cache_size = '3GB';"
sudo systemctl restart postgresql
sudo -u postgres psql -c "SHOW shared_buffers;"

Это стартовые значения, а не формула: если на том же сервере работают приложение и nginx, оставьте им запас и берите меньше. Меняйте параметры по одному и смотрите на память и время запросов. ALTER SYSTEM записывает настройки в postgresql.auto.conf, а shared_buffers вступает в силу только после перезапуска.

Какой VPS нужен PostgreSQL

Базе небольшого сайта или бота хватает 2 ГБ памяти; если база растёт и рядом работает приложение, берите 4-8 ГБ, чтобы горячие данные помещались в кеш. Подробнее - в статье сколько оперативной памяти нужно VPS. Серверы Tihost работают на NVMe-дисках, что важно для базы данных с частой записью, и стоят от $4.00 в месяц. Приложение к базе можно развернуть по инструкции Node.js на VPS.