Quanta RAM serve a un database self-hosted?

Per un'app — un'istanza Postgres o Redis più il suo backend — 1,7-2 GB è un working set realistico, quindi Small ($8) si adatta. Diverse app, o un database di produzione con concorrenza reale, ti spingono a Medium ($12), e se altre macchine devono raggiungerlo, un piano con IP dedicato. Dimensiona per working set e numero di connessioni, non per speranza.

Perché fare self-hosting invece di un database gestito?

Controllo. Ottieni l'intero postgresql.conf, il superuser, e qualsiasi estensione tu voglia — pgvector, PostGIS, TimescaleDB, pg_cron — cose che i livelli gestiti spesso bloccano o fanno pagare a parte. Il compromesso è che backup, tuning e aggiornamenti sono tuoi da gestire. Se vuoi possedere la macchina, è questo il punto.

Un VPS condiviso va bene per un database di produzione?

Per un'app da piccola a moderata, sì. Per OLTP pesante — centinaia di transazioni al secondo, scritture critiche per la latenza — una macchina a vCPU condivise è lo strumento sbagliato, e lo diremo invece di vendertene una. L'I/O del disco e un clock garantito contano lì, e i piani condivisi non promettono nessuno dei due.

Come lascio che i miei altri server si connettano al database?

Lega Postgres all'interfaccia giusta, apri la porta solo agli IP che ne hanno bisogno, e usa un piano con un IPv4 dedicato così l'indirizzo è stabile e raggiungibile. Non esporre mai la 5432 a tutto internet — mettila dietro firewall verso i tuoi server app e richiedi TLS.

Devo darvi un documento?

No. Email per registrarti, USDC o USDT per pagare. Niente documenti, root in circa un minuto.

VPS per un database

Fai self-hosting di PostgreSQL o Redis su un VPS con root completo — l'intero postgresql.conf, le estensioni che un servizio gestito non ti lascia installare, e limiti onesti su cosa una macchina condivisa può e non può reggere. Da $8/mese.

C'è un momento specifico in cui un database gestito smette di essere comodo e inizia a essere un muro. Vuoi un'estensione che il livello non offre. Vuoi vedere il vero query plan e ottimizzare work_mem. Vuoi un superuser. Un servizio gestito è un ottimo default fino al momento in cui hai bisogno di possedere la cosa — e allora un VPS con root completo è la risposta onesta.

Questa pagina parla del far girare correttamente il tuo PostgreSQL o Redis, ed è chiara su dove una macchina condivisa è la scelta giusta e dove non lo è.

Cosa serve davvero a un database

Ai database importano due cose che a un game server non importano: memoria per il working set e I/O del disco. La forma approssimativa:

Un'app — un'istanza Postgres (o Redis) più un servizio backend. Il working set è di solito 1,7-2 GB. Small ($8) lo gestisce senza drammi.
Alcune app, o concorrenza di produzione reale — più connessioni, cache più grandi, job in background. Medium ($12) ti dà il margine.
Altre macchine devono raggiungerlo — vuoi un indirizzo stabile e instradabile, quindi un piano con IPv4 dedicato (Small-IP $16 in su). Più sotto su questo.

Redis è ancora più leggero — è memory-bound, quindi dimensiona il piano al tuo dataset più l'overhead e hai finito. Postgres è quello che premia un po' di tuning.

Il vero motivo per fare self-hosting: il controllo

È qui che un VPS si guadagna il posto. Sulla tua macchina ottieni:

L'intero postgresql.conf — shared_buffers, work_mem, max_connections, le impostazioni WAL, tutto, ottimizzato sul tuo carico invece che sui default di un vendor.
Qualsiasi estensione. pgvector per embedding e ricerca semantica, PostGIS per il geospaziale, TimescaleDB per le serie temporali, pg_cron, pg_stat_statements — installa ciò che ti serve. I livelli gestiti spesso restringono la lista delle estensioni o la bloccano dietro un piano più alto.
Superuser e l'OS sotto di esso. Puoi spostare la data directory, ottimizzare il kernel, eseguire pg_dump sulla tua pianificazione, e impostare la replica in streaming verso un'altra macchina se la vuoi.

Se nulla di tutto questo ti importa, un database gestito va genuinamente bene e dovresti usarlo. Questa pagina è per il caso in cui importa.

Dove una macchina condivisa è lo strumento sbagliato

Per essere sinceri: un VPS a vCPU condivise non è costruito per OLTP pesante — centinaia di transazioni al secondo con scritture critiche per la latenza. Quel carico vive o muore sull'I/O del disco garantito e su un clock stabile, e i piani condivisi non promettono nessuno dei due. Se sei tu, vuoi hardware dedicato, e preferiamo dirtelo ora che guardare la tua latenza p99 imbarazzare entrambi.

Per il caso molto più comune — un database dietro un'app, uno strumento interno, uno store di analytics, una cache — un piano condiviso è esattamente giusto.

I backup non sono opzionali

Il self-hosting significa che i backup sono affar tuo, e l'unica regola è: falli prima di averne bisogno. Per Postgres, pg_dump su un cron per backup logici, o archiviazione WAL per il recupero point-in-time su qualsiasi cosa a cui tieni davvero. Spedisci i dump fuori dalla macchina — verso object storage o un altro server — così un disco morto non porta via i backup con sé. Testa un ripristino almeno una volta. Un backup che non hai mai ripristinato è una speranza, non un backup.

Lasciare che altri server si connettano

Se il database serve solo un'app sulla stessa macchina, legalo a localhost e hai finito — niente da esporre. Nel momento in cui un'altra macchina ha bisogno di entrare, due cose cambiano:

Ti serve un indirizzo stabile e instradabile — è un piano con IPv4 dedicato (Small-IP $16, Medium-IP $20). I piani NAT condividono un indirizzo, il che va bene per l'uscita ma non per essere un database su cui altri server compongono.
Lo metti dietro firewall duramente. Apri la 5432 (o 6379) solo agli IP specifici che ne hanno bisogno, mai a 0.0.0.0/0, e richiedi TLS. Una porta Postgres aperta su internet pubblico viene trovata in minuti.

Scegliere il piano

Setup	Piano
DB dietro un'app, solo localhost	Small ($8)
Alcune app / concorrenza di produzione	Medium ($12)
Altri server devono connettersi	Small-IP ($16) / Medium-IP ($20)
OLTP pesante, centinaia di TPS	hardware dedicato, non un VPS condiviso

La maggior parte dei database self-hosted parte da Small e cresce in Medium o un piano con IP dedicato man mano che prendono più app o client esterni.

Perché qui

Il root completo significa che è il tuo database, fino in fondo — ogni riga di config, ogni estensione, la tua pianificazione di backup, nessun livello che decide cosa ti è permesso installare. Il pagamento è crypto (USDC o USDT su Base, Ethereum o Polygon), niente KYC, niente documenti. Root in circa 60 secondi dopo il pagamento, e puoi avere Postgres che accetta connessioni qualche minuto dopo.

Il riepilogo onesto: fai self-hosting quando vuoi controllo — estensioni, tuning, superuser — e quando il tuo carico è moderato. Per il database di un'app piccola-media, un piano condiviso è lo strumento giusto. Per centinaia di TPS di OLTP critico per la latenza, non lo è, e lo diremo. Pronto? Scegli un piano.