Jest taki moment, gdy zarządzany PostgreSQL przestaje być wygodny: chcesz rozszerzenia, którego poziom nie oferuje, chcesz zobaczyć prawdziwy plan zapytania i dostroić work_mem, chcesz superużytkownika. Gdy chcesz posiadać Postgresa — konfigurację, wersję, rozszerzenia, harmonogram kopii — VPS z pełnym rootem to szczera odpowiedź. To konfiguracja specyficzna dla PostgreSQL; dla szerszego obrazu „samodzielny hosting bazy danych" (Postgres vs Redis, gdzie współdzielona maszyna jest zła) zobacz ogólny przypadek użycia bazy danych.
Dlaczego samodzielnie hostować PostgreSQL
Na własnej maszynie dostajesz to, co poziomy zarządzane reglamentują:
- Cały
postgresql.conf—shared_buffers,work_mem,max_connections, ustawienia WAL, dostrojone do twojego obciążenia, a nie domyślne u dostawcy. - Dowolne rozszerzenie.
pgvectordo embeddingów,PostGISdo geoprzestrzennych,TimescaleDBdo szeregów czasowych,pg_cron,pg_stat_statements— instaluj, czego potrzebujesz. To tu poziom zarządzany najczęściej mówi nie. - Twoja wersja główna, aktualizowana według twojego harmonogramu, nie dostawcy.
- Superużytkownik i system operacyjny pod spodem — przenieś katalog danych, dostrój jądro, uruchom replikację strumieniową na drugą maszynę.
Jeśli pgvector jest powodem, dla którego tu jesteś, zauważ, że Postgres plus pgvector to kompletny magazyn wektorów na jednej maszynie — ten sam element składowy za samodzielnie hostowanym stosem RAG i pamięcią agenta.
Skonfiguruj to (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;"
Związany z 127.0.0.1, obsługuje aplikację na tej samej maszynie, nic nie wystawiając. Aby wpuścić inne serwery — to następna sekcja.
Pozwolić innym serwerom się łączyć — bezpiecznie
W chwili gdy inna maszyna potrzebuje bazy danych, zmieniają się dwie rzeczy:
- Stabilny, routowalny adres — plan z dedykowanym IPv4 (Small-IP $16, Medium-IP $20). Plany NAT współdzielą wychodzące IP, dobre do wychodzącego, ale nie do bycia bazą, do której inni się dobijają.
- Twardy firewall. Otwórz 5432 tylko dla konkretnych IP klientów, nigdy
0.0.0.0/0, i wymuś TLS. Otwarty port Postgresa w publicznym internecie zostaje znaleziony w kilka minut — zablokuj go firewallem UFW.
Kopie zapasowe to twoje zadanie
Samodzielny hosting oznacza, że kopie zapasowe są na tobie, a zasada brzmi: rób je, zanim będą potrzebne. pg_dump w cronie do kopii logicznych albo archiwizacja WAL do odzyskiwania do punktu w czasie dla wszystkiego, na czym ci zależy. Wysyłaj zrzuty poza maszynę i przetestuj odtworzenie choć raz — kopia, której nigdy nie odtworzyłeś, to nadzieja, nie kopia. Dostępny jest dodatek zarządzanych kopii zapasowych, jeśli wolisz nie prowadzić tego samodzielnie.
Dlaczego EQVPS pod PostgreSQL
- Pełny root, superużytkownik, twoja konfiguracja — od 8 $/mies, NVMe (RAID1), które ma znaczenie, gdy baza i jej WAL piszą naraz.
- Bez KYC, płatność krypto. E-mail do rejestracji, USDC/USDT do zapłaty.
- UE (Niemcy, Finlandia), root w ~60 sekund. Przynieś swój schemat i ruszaj.
Ogólny przypadek użycia bazy danych (przegląd Postgres/Redis) → · Samodzielnie hostowany RAG na skalę →
Komentarze
Brak komentarzy. Bądź pierwszy.