VPS для бази даних PostgreSQL (самохостинг, повний контроль)

Настає момент, коли керований PostgreSQL перестає бути зручним: вам потрібне розширення, якого рівень не пропонує, ви хочете бачити реальний план запиту й налаштувати work_mem, вам потрібен суперкористувач. Коли ви хочете володіти Postgres — конфігом, версією, розширеннями, графіком резервних копій — VPS із повним root є чесною відповіддю. Це налаштування, специфічне для PostgreSQL; для ширшої картини «самохостинг бази даних» (Postgres проти Redis, де спільна машина неправильна) дивіться загальний кейс бази даних.

Навіщо хостити PostgreSQL самостійно

На власній машині ви отримуєте те, що керовані рівні видають порціями:

• Весь postgresql.conf — shared_buffers, work_mem, max_connections, налаштування WAL, підлаштовані під ваше навантаження, а не дефолт вендора.
• Будь-яке розширення. pgvector для ембедингів, PostGIS для геопросторових даних, TimescaleDB для часових рядів, pg_cron, pg_stat_statements — встановлюйте те, що потрібно. Саме тут керований рівень найчастіше каже «ні».
• Ваша мажорна версія, оновлена за вашим графіком, а не провайдера.
• Суперкористувач і ОС під ним — перенесіть каталог даних, налаштуйте ядро, запустіть потокову реплікацію на другу машину.

Якщо pgvector — причина, чому ви тут, зауважте, що Postgres-плюс-pgvector — це повноцінне векторне сховище на одній машині — той самий будівельний блок за самохостинг RAG-стеком і пам'яттю агента.

Налаштуйте це (Ubuntu 24.04, Docker)

# docker-compose.yml — PostgreSQL 16 (+ pgvector via the pgvector image)
services:
  db:
    image: pgvector/pgvector:pg16
    restart: always
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: change-me-strong
      POSTGRES_DB: app
    command: ["postgres", "-c", "shared_buffers=512MB", "-c", "work_mem=32MB"]
    volumes: ["/srv/pg:/var/lib/postgresql/data"]
    ports: ["127.0.0.1:5432:5432"]   # localhost only; see below to expose safely

docker compose up -d
docker compose exec db psql -U app -c "CREATE EXTENSION IF NOT EXISTS vector;"

Прив'язаний до 127.0.0.1, він обслуговує застосунок на тій самій машині, нічого не відкриваючи. Щоб впустити інші сервери — це наступний розділ.

Дозволити іншим серверам підключатися — безпечно

Щойно іншій машині знадобиться база даних, змінюються дві речі:

1. Стабільна маршрутизована адреса — план із виділеним IPv4 (Small-IP $16, Medium-IP $20). NAT-плани ділять вихідний IP, що годиться для вихідного трафіку, але не для того, щоб бути базою даних, до якої підключаються інші.
2. Жорсткий фаєрвол. Відкрийте 5432 лише для конкретних клієнтських IP, ніколи 0.0.0.0/0, і вимагайте TLS. Відкритий порт Postgres у публічному інтернеті знаходять за хвилини — заблокуйте його фаєрволом UFW.

Резервні копії — ваша робота

Самохостинг означає, що резервні копії на вас, і правило таке: робіть їх до того, як вони знадобляться. pg_dump за cron для логічних резервних копій або архівування WAL для відновлення на момент часу для всього, що вам важливе. Відправляйте дампи з машини й перевірте відновлення хоча б раз — резервна копія, яку ви ніколи не відновлювали, — це надія, а не резервна копія. Add-on керованих резервних копій доступний, якщо ви радше не хочете робити це самі.

Чому EQVPS для PostgreSQL

• Повний root, суперкористувач, ваш конфіг — від $8/міс, NVMe (RAID1), що має значення, щойно база даних і її WAL пишуть водночас.
• Без KYC, оплата криптою. Email для реєстрації, USDC/USDT для оплати.
• ЄС (Німеччина, Фінляндія), root за ~60 секунд. Приносьте свою схему й уперед.

Загальний кейс бази даних (огляд Postgres/Redis) → · Самохостинг RAG у масштабі →