Как установить PostgreSQL на Ubuntu: база, пользователь и подключение

PostgreSQL нужен, когда приложению требуется реляционная база: пользователи, заказы, записи, связи между ними и транзакции. Здесь установим сервер из репозитория Ubuntu, создадим отдельную роль приложения и проверим подключение с паролем. Пример подходит для одного VPS, на котором работают и приложение, и база.

Проверено 29 октября 2026 года: Ubuntu 24.04.5 LTS, PostgreSQL 16.15 из стандартного репозитория Ubuntu. Номер обновления пакета со временем меняется. Если нужен другой основной выпуск, сначала проверьте требования приложения и официальные варианты установки PostgreSQL.

Что подготовить

Нужен VPS с Ubuntu 24.04, SSH-доступом и пользователем с sudo. Команды рассчитаны на новый сервер без существующих баз PostgreSQL. На рабочем сервере сначала выясните, какая версия и какие кластеры уже используются, и сделайте копии.

Имя роли и базы в примере — hf_app. Это учебное имя: можете выбрать своё, заменив его во всех командах. Домен и сертификат для локального подключения базы не нужны. Порт 5432 не требуется открывать в UFW.

Установить пакеты и проверить кластер

sudo apt update
sudo apt install postgresql postgresql-client
pg_lsclusters
sudo -u postgres psql -X -c 'SHOW server_version;'

На нашем стенде появился кластер 16 main, порт 5432, состояние online. Кластер здесь означает отдельный экземпляр PostgreSQL с каталогом данных и набором баз. Несколько установленных версий могут иметь разные порты, поэтому ориентируйтесь на фактический вывод pg_lsclusters.

sudo systemctl status postgresql@16-main --no-pager
pg_isready -h 127.0.0.1 -p 5432
sudo ss -ltnp '( sport = :5432 )'

Общая служба postgresql.service в Ubuntu может показывать active (exited): это ещё не подтверждение работы конкретного кластера. Для проверенного примера смотрим postgresql@16-main и ответ pg_isready. При другой версии замените имя службы. На этом этапе слушатель должен быть локальным, например 127.0.0.1:5432 и [::1]:5432.

Создать роль приложения без административных прав

Откройте административную консоль от системного пользователя postgres:

sudo -u postgres psql -X

Внутри выполните:

CREATE ROLE hf_app LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE;
\password hf_app
CREATE DATABASE hf_app OWNER hf_app TEMPLATE template0 ENCODING 'UTF8';
\q

Команда \password дважды запросит новый пароль без вывода на экран. Создайте уникальный пароль и сохраните его в менеджере паролей. Не вставляйте пароль в строку SQL, команду оболочки или публичный репозиторий. Если роль уже существует, остановитесь и проверьте её назначение: повторный запуск всего блока не является способом обновления существующей базы.

Роль владеет своей базой и может создавать в ней таблицы, но не получает права суперпользователя, создания других баз или ролей. Для проекта с отдельным процессом миграций права рабочего приложения можно ограничить ещё сильнее; здесь показан простой старт с одним владельцем.

Проверить парольное подключение и запись данных

Теперь подключитесь по TCP как приложение, а не через административного пользователя:

psql -X -h 127.0.0.1 -p 5432 -U hf_app -d hf_app -W

Введите пароль роли, затем выполните:

SELECT current_database(), current_user;
CREATE TABLE lessons (
    id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    title text NOT NULL
);
INSERT INTO lessons (title) VALUES
    ('Первое подключение'),
    ('Резервная копия'),
    ('Проверка восстановления');
SELECT id, title FROM lessons ORDER BY id;
\q

Ожидаем базу и пользователя hf_app, затем три записи. Таблица lessons нужна только для упражнения; не создавайте её повторно в существующей базе приложения. Мы также проверили на стенде, что попытка этой роли создать другую роль завершается отказом в доступе.

Почему возникает Peer authentication failed

Подключение psql -U hf_app без -h обычно идёт через Unix-сокет. В стандартной конфигурации Ubuntu для локальных сокетов используется peer: PostgreSQL сопоставляет системного пользователя с ролью базы. Поэтому подключение из-под другого пользователя Linux может не пройти даже с правильно заданным именем роли.

Для приложения на том же VPS используйте проверенный вариант -h 127.0.0.1 и пароль. Посмотреть фактические файлы конфигурации можно так:

sudo -u postgres psql -X -c 'SHOW hba_file;'
sudo -u postgres psql -X -c 'SHOW listen_addresses;'

Не заменяйте методы аутентификации на trust ради устранения ошибки. При ошибке password authentication failed проверьте роль, базу, порт и пароль. При connection refused сначала проверьте состояние кластера и слушатель. Различие сокета и TCP описано в документации peer-аутентификации.

Как подключить приложение

Укажите в настройках приложения host 127.0.0.1, port 5432, database и user hf_app. Передайте пароль через механизм секретов приложения или файл окружения, доступный только владельцу службы. Строку подключения и файлы с секретами не публикуйте. При URL-формате специальные символы пароля требуют корректного кодирования.

Если база и приложение находятся на разных серверах, это уже другой сценарий: нужны правила сети, аутентификации и защиты соединения. Открывать 0.0.0.0:5432 всем адресам для текущего примера не требуется. Основы ограничения входящих соединений разобраны в инструкции по UFW.

Что проверить до запуска проекта

Убедитесь, что роль подключается и читает свои данные, кластер запускается как служба, а база недоступна из интернета. Следующий обязательный шаг — резервная копия PostgreSQL с проверкой восстановления. Файл дампа без тестового восстановления ещё не подтверждает готовность к аварии.

Если само приложение ещё не развёрнуто, используйте отдельные руководства по Node.js или FastAPI. Они показывают запуск службы и подключение Nginx; модель данных и миграции вашего проекта настраиваются отдельно.