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). Sui piani NAT l'indirizzo in uscita non è tuo, 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 →

Come installare PostgreSQL su un VPS e collegarsi in sicurezza →