VPS PostgreSQL მონაცემთა ბაზისთვის (თვით-ჰოსტინგი, სრული კონტროლი)

დგება მომენტი, როცა მართული PostgreSQL წყვეტს მოხერხებული ყოფნას: გინდათ გაფართოება, რომელსაც დონე არ გთავაზობთ, გინდათ დაინახოთ ნამდვილი მოთხოვნის გეგმა და მოარგოთ work_mem, გინდათ სუპერმომხმარებელი. როცა გინდათ ფლობდეთ Postgres-ს — კონფიგურაცია, ვერსია, გაფართოებები, სარეზერვო გრაფიკი — სრული root-ის მქონე VPS პატიოსანი პასუხია. ეს PostgreSQL-სთვის სპეციფიკური დაყენებაა; უფრო ფართო „მონაცემთა ბაზის თვით-ჰოსტინგის" სურათისთვის (Postgres vs Redis, სად არის გაზიარებული მანქანა არასწორი) იხილეთ ზოგადი მონაცემთა ბაზის გამოყენების შემთხვევა.

რატომ თვითონ უმასპინძლოთ PostgreSQL-ს

თქვენივე მანქანაზე იღებთ იმას, რასაც მართული დონეები ულუფად გცემენ:

• მთელი postgresql.conf — shared_buffers, work_mem, max_connections, WAL პარამეტრები, მორგებული თქვენს დატვირთვას და არა მომწოდებლის ნაგულისხმევს.
• ნებისმიერი გაფართოება. pgvector ჩაშენებებისთვის, PostGIS გეოსივრცითისთვის, TimescaleDB დროის მწკრივებისთვის, pg_cron, pg_stat_statements — დააყენეთ ის, რაც გჭირდებათ. სწორედ აქ ამბობს მართული დონე ყველაზე ხშირად უარს.
• თქვენი მთავარი ვერსია, განახლებული თქვენი გრაფიკით და არა მომწოდებლის.
• სუპერმომხმარებელი და მის ქვეშ OS — გადაიტანეთ მონაცემთა დირექტორია, მოარგეთ ბირთვი, გაუშვით სტრიმინგ რეპლიკაცია მეორე მანქანაზე.

თუ 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 არქივირება point-in-time აღდგენისთვის ყველაფრისთვის, რაც გაინტერესებთ. გაუშვით dump-ები მანქანის გარეთ და გამოცადეთ აღდგენა ერთხელ მაინც — სარეზერვო ასლი, რომელიც არასდროს აღგიდგენიათ, იმედია და არა სარეზერვო ასლი. მართული სარეზერვო ასლების დანამატი ხელმისაწვდომია, თუ გირჩევნიათ თვითონ არ გაუშვათ.

რატომ EQVPS PostgreSQL-სთვის

• სრული root, სუპერმომხმარებელი, თქვენი კონფიგურაცია — $8/თვე-დან, NVMe (RAID1), რომელსაც მნიშვნელობა აქვს, როგორც კი მონაცემთა ბაზა და მისი WAL ერთდროულად წერენ.
• KYC-ის გარეშე, კრიპტო გადახდა. ელფოსტა რეგისტრაციისთვის, USDC/USDT გადასახდელად.
• ევროკავშირი (გერმანია, ფინეთი), root ~60 წამში. მოიტანეთ თქვენი სქემა და წადით.

ზოგადი მონაცემთა ბაზის გამოყენების შემთხვევა (Postgres/Redis მიმოხილვა) → · თვით-ჰოსტინგზე გამართული RAG მასშტაბით →