VPS per un database PostgreSQL (self-hosted, controllo totale)

C'è un momento in cui PostgreSQL gestito smette di essere comodo: vuoi un'estensione che il livello non offre, vuoi vedere il vero piano di query e regolare work_mem, vuoi il superuser. Quando vuoi possedere Postgres — la configurazione, la versione, le estensioni, il calendario dei backup — un VPS con root completo è la risposta onesta. Questa è la configurazione specifica di PostgreSQL; per il quadro più ampio "self-host di un database" (Postgres vs Redis, dove una macchina condivisa è sbagliata) vedi il caso d'uso database generale.

Perché fare self-host di PostgreSQL

Sulla tua macchina ottieni ciò che i livelli gestiti razionano:

• L'intero postgresql.conf — shared_buffers, work_mem, max_connections, impostazioni WAL, regolati sul tuo carico, non un default del fornitore.
• Qualsiasi estensione. pgvector per gli embedding, PostGIS per il geospaziale, TimescaleDB per le serie temporali, pg_cron, pg_stat_statements — installa ciò che ti serve. È qui che un livello gestito dice no più spesso.
• La tua versione maggiore, aggiornata sul tuo calendario, non su quello del fornitore.
• Superuser e il sistema operativo sotto — sposta la directory dei dati, regola il kernel, esegui la replica in streaming verso una seconda macchina.

Se pgvector è il motivo per cui sei qui, nota che Postgres più pgvector è un vector store completo su una sola macchina — lo stesso blocco di costruzione dietro uno stack RAG self-hosted e la memoria dell'agente.

Configuralo (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;"

Vincolato a 127.0.0.1, serve un'app sulla stessa macchina senza esporre nulla. Per far entrare altri server, è la sezione successiva.

Lasciar connettere altri server — in sicurezza

Nel momento in cui un'altra macchina ha bisogno del database, cambiano due cose:

1. Un indirizzo stabile e instradabile — un piano con IPv4 dedicato (Small-IP $16, Medium-IP $20). I piani NAT condividono un IP in uscita, ottimo per l'uscita ma non per essere un database che altri chiamano.
2. Firewall serrato. Apri la 5432 solo agli IP client specifici, mai 0.0.0.0/0, e richiedi TLS. Una porta Postgres aperta sull'internet pubblico viene trovata in minuti — bloccala con un firewall UFW.

I backup sono compito tuo

Il self-hosting significa che i backup spettano a te, e la regola è: falli prima di averne bisogno. pg_dump su un cron per backup logici, o l'archiviazione WAL per il recupero point-in-time su tutto ciò che ti importa. Spedisci i dump fuori dalla macchina, e prova un ripristino almeno una volta — un backup che non hai mai ripristinato è una speranza, non un backup. Un add-on di backup gestiti è disponibile se preferisci non gestirlo da solo.

Perché EQVPS per PostgreSQL

• Root completo, superuser, la tua configurazione — da $8/mese, NVMe (RAID1) che conta appena un database e il suo WAL scrivono insieme.
• Niente KYC, pagamento cripto. Email per registrarti, USDC/USDT per pagare.
• UE (Germania, Finlandia), root in ~60 secondi. Porta il tuo schema e vai.

Caso d'uso database generale (panoramica Postgres/Redis) → · RAG self-hosted su scala →