PostgreSQL Autogestito su un VPS: Sfuggi ai Costi dei Database Gestiti

Elaborazione. Archiviazione. Conservazione dei backup.

L’esportazione dello snapshot di cui ti sei dimenticato. La tariffa di uscita dall’ambiente di staging che ha eseguito un ‘pg_dump’ martedì scorso.

Nessuno apre la propria fattura del database gestito aspettandosi che sia economica.

Ma, cavolo.

Il divario tra “Postgres per $25 al mese” e ciò che appare sulla carta si è allargato, e un VPS da 4 GB al prezzo di un singolo add-on Supabase ora gestisce l’intero database con spazio a sufficienza per permettere al sistema operativo di memorizzare nella cache le pagine più frequentate.

Ospitare autonomamente un database Postgres di produzione non è più l’incubo operativo di una volta. Il repository del PostgreSQL Global Development Group (PGDG) è solido; le installazioni moderne di PostgreSQL (v14+) predefiniscono la crittografia della password SCRAM-SHA-256, con il vecchio MD5 ufficialmente deprecato a partire dalla v18. I motivi per cui le persone rimangono su RDS, Supabase o Neon oggi sono operativi, non tecnici.

Stiamo parlando di fatture reali, di costi operativi effettivi e di come appare realmente l’hosting moderno di Postgres.

Quanto Costa Effettivamente L’Hosting Autonomo di PostgreSQL su un VPS?

PostgreSQL auto-ospitato su un VPS da 4 GB funziona comunemente a una frazione del prezzo equivalente di RDS, Supabase Pro o Neon Scale una volta che lo storage, i backup e l’egress sono inclusi nella fattura gestita.

PostgreSQL è il database utilizzato dal 55,6% degli sviluppatori, secondo il Sondaggio degli Sviluppatori 2025 di Stack Overflow, il più popolare degli ultimi due anni. È anche il database che puoi gestire comodamente da solo.

Confronto per un carico di lavoro rappresentativo di un piccolo team (4 GB di RAM, ~100 GB di dati, carico di scrittura da basso a moderato, singola regione), con prezzi aggiornati a maggio 2026:

Opzione	Elaborazione	Archiviazione	Trasferimento dati oltre il limite gratuito	Ideale per
Autogestito su un VPS da 4 GB	Prezzo fisso	Di solito incluso	Di solito non misurato o alta capacità	Carichi di lavoro costanti, team attenti ai costi e a loro agio con Linux
AWS RDS db.t4g.medium	$47,45/mese solo elaborazione	~$0,115/GB-mese gp3	~$0,09/GB internet/fuori regione	Team che desiderano backup gestiti, failover e operazioni native AWS
Supabase Pro	$25/mese base + utilizzo	$0,125/GB disco database oltre gli 8 GB inclusi	$0,09/GB oltre 250 GB	App che necessitano di Postgres, autenticazione, archiviazione e tempo reale in un unico stack
Neon Scale	$0,222 per CU/ora	$0,35 per GB/mese	Misurato sull’uso	Workflows di sviluppo con picchi, anteprime frequenti e molti branch

Il prezzo on-demand del RDS db.t4g.medium è di circa $0,065 all’ora, o circa $47,45 al mese solo per l’elaborazione.

Aggiungi 100 GB di archiviazione gp3 a circa $0.115/GB-mese con backup automatici, e un box Single-AZ si aggira intorno ai $60/mese. Attiva il failover Multi-AZ e la linea di elaborazione raddoppia circa, portando una configurazione di grado produttivo a $100/mese e oltre.

Non è una piccola differenza.

Self-hosting è più economico perché tu fai il lavoro che la fattura gestita stava pagando. Disciplina operativa, reperibilità, alle 2 di notte quando il disco si riempie. L’alternativa del DB gestito con cui stai facendo i confronti potrebbe avere un limite diverso il prossimo trimestre, quindi fai i conti con la tua fattura prima di impegnarti.

Quando Ha Senso L’Auto-Hosting Di PostgreSQL?

Self-hosting di PostgreSQL su un VPS ha senso quando hai una conoscenza di base di Linux nel team, un carico di lavoro costante, una dimensione del set di lavoro prevedibile e un motivo valido per evitare la fattura gestita.

Non funziona quando non hai capacità operative, requisiti HA regolamentati che non puoi costruire da solo, o un modello a raffiche che beneficia di una scalabilità istantanea.

Tre fattori guidano questa decisione. Costo, privacy e sovranità dei dati, e controllo.

Dove l’auto-ospitato vince chiaramente:

• Traffico costante in una singola regione con un set di lavoro prevedibile.
• App SaaS di piccole e medie dimensioni con un database Postgres e un team a suo agio con Linux.
• Carichi di lavoro sensibili alla privacy dove il database non dovrebbe trovarsi nella tenuta di qualcun altro.
• Team attenti ai costi il cui conto gestito ha superato la soglia di fastidio operativo.

Dove la gestione si impone con chiarezza:

• Carichi di lavoro a raffica che traggono vantaggio dall’escalation e dalla riduzione istantanee.
• Configurazioni multi-regione dove la replica globale è il prodotto.
• Ambienti regolamentati che necessitano di soluzioni HA pronte all’uso, certificazioni di conformità e tracce di verifica.
• Squadre senza capacità operative disponibili e senza piani per svilupparle.

Il numero del risparmio sui costi dal 40% al 60% viene citato spesso. Annotalo con attenzione.

Dal 2021, l’autore AWS Rupesh Desai ha documentato PostgreSQL su EC2 in esecuzione dal 40% al 60% più economico rispetto a RDS a specifiche equivalenti, più vecchio della maggior parte delle attuali famiglie di istanze RDS.

La versione attuale è l’analisi del costo-stack di byteiota, pubblicata alla fine del 2025, che indica che RDS è dal 75% all’88% più costoso rispetto all’hardware dedicato equivalente.

Il pareggio onesto è nelle ore operative, non nel costo del server.

Come Scegliere La Dimensione Giusta Del VPS Per PostgreSQL?

La maggior parte dei database delle applicazioni in produzione funziona comodamente con 4 GB di RAM e archiviazione NVMe. I dataset più grandi, le connessioni concorrenti intense o i carichi di lavoro di analisi spingono il requisito a 8 GB o 16 GB e oltre.

La RAM determina quanto del tuo set di lavoro Postgres può mantenere in memoria; una volta che le pagine attive vengono trasferite su disco, le query rallentano. NVMe è importante perché Postgres è sensibile alla latenza di lettura casuale per le pagine attive e alla velocità di svuotamento per il registro di scrittura anticipata.

Le indicazioni comuni per il tuning di PostgreSQL iniziano con:

• shared_buffers a circa il 25% della RAM del sistema.
• effective_cache_size a circa il 50%-75% della RAM del sistema.
• work_mem dimensionato in modo conservativo — basato sulla complessità della query concorrente, non solo sulla RAM totale.

Su un VPS da 4 GB, ciò significa solitamente allocare circa 1 GB a shared_buffers lasciando abbastanza memoria per la cache delle pagine di Linux per contenere dati frequentemente accessi. Questo equilibrio è parte del motivo per cui una modesta scatola da 4 GB può gestire comodamente molti carichi di lavoro di produzione di piccole e medie dimensioni.

La mappa piano-carico di lavoro che devi conoscere:

Livello di RAM	Carico di lavoro tipico	Piano Stack consigliato
2 GB	Ambienti di sviluppo, progetti secondari a basso traffico	Sotto la base
4 GB	La maggior parte delle basi di dati delle applicazioni in produzione	Stack 4
8 GB	Set di dati più grandi, più connessioni contemporanee	Stack 8
16 GB+	Postgres insieme ad altri servizi pesanti, analisi	Stack 16

I piani di Hosting VPS di DreamHost ti offrono accesso Root, archiviazione NVMe e larghezza di banda illimitata con una fatturazione mensile prevedibile.

Queste sono le quattro cose di cui dipende un carico di lavoro Postgres auto-ospitato.

Come Installi PostgreSQL Su Un VPS?

Installi PostgreSQL su un VPS in cinque passaggi compatti.

1. Configura il VPS: Scegli un piano con abbastanza RAM per il tuo set di lavoro (Stack 4/4 GB è il punto di partenza). Ubuntu 24.04 LTS è il sistema operativo consigliato. Collegati con autenticazione basata su chiave, non con una password.
2. Installa dal repo ufficiale PGDG: La distribuzione ‘apt install postgresql’ è indietro di diverse versioni principali. Aggiungi il repo apt di PGDG, poi ‘sudo apt install postgresql-18.’ Conferma con ‘sudo systemctl status postgresql’
3. Imposta la password di postgres e crea il tuo ruolo per l’app: Esegui sudo -i -u postgres, poi psql, poi password postgres. Crea un ruolo dedicato con i minimi privilegi: ‘CREATE ROLE myapp WITH LOGIN PASSWORD '...';’ e ‘CREATE DATABASE myapp_prod OWNER myapp;’
4. Configura correttamente il listener: Apri /etc/postgresql/18/main/postgresql.conf. Imposta listen_addresses = ‘localhost’ se l’app e il database condividono il server, o associa a un IP privato se l’app gira su un VPS separato. Evita di associare PostgreSQL a 0.0.0.0 su un’interfaccia pubblicamente accessibile. Le istanze di PostgreSQL esposte vengono scannerizzate e forzate brutalmente da bot automatizzati.
5. Proteggi ‘pg_hba.conf’ e UFW: Modifica pg_hba.conf per permettere solo gli IP dell’applicazione di cui hai effettivamente bisogno, con ‘scram-sha-256’ come metodo di autenticazione. Configura UFW per permettere la porta 5432 solo da quegli stessi IP. Usa un tunnel SSH per gli strumenti di amministrazione (e per favore non aprire la 5432 all’internet pubblico).

Prova questo da un’altra macchina: psql -h <vps-ip> -U postgres.

Un timeout o una connessione rifiutata da un IP non autorizzato di solito significa che il tuo listener e le regole del firewall stanno facendo il loro lavoro. Una richiesta di password dall’internet pubblico significa che qualcosa è configurato male. Una volta che Postgres è in esecuzione, la configurazione è solo metà del lavoro.

Come Si Protegge PostgreSQL Su Un VPS?

PostgreSQL su un VPS è protetto su tre livelli, oltre all’igiene dei ruoli e alla cadenza delle patch.

1. Autenticazione: Usa scram-sha-256 per le nuove installazioni e rimuovi le regole legacy md5 da pg_hba.conf. I documenti di PostgreSQL ora avvertono che il supporto per le password criptate con MD5 è deprecato e sarà rimosso in una futura release.
2. Rete: Associa PostgreSQL a ‘localhost,’ un IP privato, o un’interfaccia raggiungibile solo dai tuoi server applicativi. Evita di associarlo a un’interfaccia pubblicamente raggiungibile. Sovrapponi UFW e permetti la porta 5432 solo dagli IP dell’applicazione fidati.
3. Crittografia in transito: Attiva TLS per qualsiasi connessione che attraversa un confine di rete. Imposta ssl = on in postgresql.conf, poi usa le regole hostssl … scram-sha-256 in pg_hba.conf affinché i client non possano passare silenziosamente a connessioni senza TLS. I certificati autofirmati sono accettabili per il traffico interno se i client li verificano correttamente.
4. Ruoli: Le connessioni delle applicazioni dovrebbero usare un ruolo di minimo privilegio con solo i diritti necessari per gli schemi di quell’app. Il superutente è per le migrazioni e le emergenze.
5. Aggiornamenti: Usa il repository apt PGDG per i pacchetti PostgreSQL attuali. Abilita gli aggiornamenti di sicurezza non supervisionati per il sistema operativo, ma pianifica deliberatamente gli aggiornamenti di PostgreSQL così un riavvio a sorpresa non diventa il tuo incidente della settimana. 

La tua checklist di sicurezza:

• Utilizza solo scram-sha-256; disabilita md5.
• Imposta ‘listen_addresses’ su localhost o IP privato.
• Le regole UFW consentono solo il 5432 da IP fidati.
• SSL/TLS attivato per qualsiasi connessione che attraversa la rete.
• L’app si connette come un ruolo con i minori privilegi, mai come ‘postgres’.
• Aggiornamenti di sicurezza non supervisionati abilitati.
• Nessuna linea ‘host all all 0.0.0.0/0 md5’ presente in ‘pg_hba.conf’, mai.

Quell’ultimo punto è la storia di avvertimento.

La porta pubblica 5432 con credenziali deboli è un noto obiettivo di cryptominer e attacchi brute-force. Le istanze PostgreSQL esposte vengono continuamente scansionate da bot automatizzati alla ricerca di account predefiniti, password trapelate o regole permissive di pg_hba.conf.

Le istanze di Postgres accessibili pubblicamente con autenticazione debole vengono compromesse incredibilmente velocemente. Un database esposto direttamente a internet senza adeguati controlli di rete, TLS e isolamento dei ruoli è il tipo di errore che si trasforma in un rapporto di incidente. Un database configurato correttamente è comunque a una sola guasto del disco dalla perdita di dati.

Come Effettuare il Backup e la Replica di PostgreSQL su un VPS?

I backup di PostgreSQL su un VPS utilizzano uno tra tre meccanismi, scelti in base al tipo di errore da cui ti stai proteggendo. Backup logici tramite pg_dump per la portabilità, backup fisici tramite pg_basebackup più archiviazione WAL per il recupero a un punto specifico nel tempo, e la replica in streaming per l’alta disponibilità.

I backup logici gestiscono migrazioni, ripristini parziali e aggiornamenti di sviluppo. Esegui pg_dump –format=custom –file=mydb.dump mydb_prod da un Cron Job giornaliero. Il formato personalizzato comprime bene e, insieme al formato directory, supporta le opzioni di ripristino parallelo e selettivo di pg_restore. Spingi il dump verso l’Object Storage esterno a VPS (DreamObjects, compatibile con S3).

I backup fisici gestiscono il ripristino completo del sistema e il recupero a un punto specifico nel tempo. pg_basebackup unito all’archiviazione continua del Log di Anticipo Scrittura (WAL) ti permette di recuperare a qualsiasi momento tra l’ultimo backup di base e il segmento WAL più recente, l’opzione di livello produttivo quando la tolleranza alla perdita di dati è di secondi, non ore.

La replica in streaming è la terza opzione. Una replica di lettura su un secondo VPS è una copia di riserva attiva per carichi di lavoro intensivi in lettura o un obiettivo di failover rapido. La configurazione della replica del database richiede un secondo VPS ma limita il tuo peggior caso di interruzione a pochi minuti.

Mechanismo	Cosa Ti Offre	Cosa Costa
pg_dump + cron + archiviazione off-VPS	Backup logico giornaliero, portatile	Latenza di ripristino, non al punto temporale
pg_basebackup + archiviazione WAL	Backup fisico con recupero al punto temporale	Complessità operativa e di archiviazione
Replicazione continua	Standby attivo, obiettivo di recupero quasi zero (RPO), scalabilità di lettura	Secondo VPS più gestione della replicazione

Ripristino-test mensile. I servizi gestiti includono tutto questo, ed è parte di ciò che il risparmio dell’auto-ospitato sta recuperando. Se sei già su un fornitore gestito, il percorso per uscire è più semplice di quanto sembri.

Come Si Migra Da RDS, Supabase o Neon a Un VPS?

Migri da un fornitore gestito di Postgres a un VPS in quattro passaggi.

1. Configura il VPS di destinazione: Assicurati che la versione maggiore di Postgres sul server sorgente sia esattamente la stessa. Installa PostgreSQL sul nuovo VPS seguendo i passaggi sopra, poi crea in anticipo il ruolo dell’applicazione e il database.
2. Esporta dalla fonte: Esegui pg_dump –format=custom –no-owner –no-privileges –file=src.dump <source-connection-string>. Le opzioni –no-owner e –no-privileges eliminano i permessi specifici del fornitore che raramente si ricreano correttamente su un nuovo host.
3. Ripristina sul destinatario: Esegui pg_restore –dbname=myapp_prod –jobs=4 –no-owner –no-privileges src.dump. Attento agli avvisi sulle estensioni. RDS, Supabase e Neon spesso abilitano estensioni che potrebbero non esistere su un Postgres standard. Installa estensioni compatibili dai pacchetti PGDG o postgresql-contrib prima di ripristinare.
4. Scambio e verifica della stringa di connessione: Punto un ambiente di staging al nuovo VPS per primo, esegui la tua suite di test, poi convalida le query di produzione rappresentative e i flussi dell’applicazione prima di cambiare la stringa di connessione di produzione. Per le applicazioni con scritture limitate, una breve finestra di manutenzione durante il passaggio finale è spesso più semplice che impostare la replicazione. Mantieni il database sorgente online e in sola lettura per alcuni giorni come target di rollback.

Cosa cambia in base al fornitore?

1. Da RDS: I ruoli specifici di RDS (‘rds_superuser,’ ‘rdsadmin’) non esistono nel Postgres standard; –no-owner e –no-privileges gestiscono la maggior parte delle operazioni. Alcune estensioni gestite da RDS necessitano di un’installazione manuale e l’uscita da AWS durante il dump è soggetta a tariffazione.
2. Da Supabase: Il Postgres di Supabase è un vero Postgres, ma gli strati di autenticazione, archiviazione e edge di Supabase non si migrano. Lo schema della tua applicazione sì. Sostituisci questi strati con equivalenti auto-ospitati prima di procedere al passaggio.
3. Da Neon: La funzionalità di branching scompare dopo la migrazione; pianifica invece i backup. Il processo di dump e ripristino è semplice, ma le abitudini operative come i branch istantanei necessitano di un flusso di lavoro sostitutivo.

La migrazione di per sé di solito richiede meno tempo rispetto alla scelta del piano VPS. Il tempo di inattività realistico è di pochi minuti per piccoli database, più lungo con la riproduzione WAL per quelli grandi. La maggior parte delle installazioni si ferma qui, ma c’è uno scenario che ti spinge oltre…

Quando Aggiungere PgBouncer o Mantenere Vanilla Postgres?

La maggior parte delle app su un VPS da 4 GB non richiede un gestore di pool di connessioni all’inizio. Aggiungi PgBouncer quando le connessioni contemporanee superano circa 100, o il tuo stack di applicazioni apre una nuova connessione per ogni richiesta.

Le connessioni PostgreSQL sono pesanti perché ognuna è un processo completo del sistema operativo. Con 4 GB di RAM, non vuoi centinaia di connessioni inattive che consumano memoria. Il pooler mantiene le costose connessioni Postgres dal suo lato e distribuisce connessioni economiche e di breve durata alla tua app dall’altro.

Due modalità di pooling rilevanti:

• Session pooling: Ogni client ottiene una connessione al server per la sessione. Sicuro per qualsiasi app, nessun cambiamento semantico, guadagno di throughput minore.
• Transaction pooling: Ogni client ottiene una connessione al server per una transazione. Grande guadagno di throughput. Si perdono funzionalità che dipendono dallo stato della sessione (dichiarazioni preparate, blocchi consultivi, ‘LISTEN’/’NOTIFY’) a meno che l’app non sia scritta per aspettarselo.

La maggior parte delle piccole applicazioni SaaS con un ORM che utilizza un pool di connessioni va bene senza PgBouncer fino a quando non è più così. Il segnale che hai superato il limite è l’errore ‘FATAL: too many connections’ o la pressione sulla memoria da connessioni inattive.

Installa con sudo apt install pgbouncer, configura /etc/pgbouncer/pgbouncer.ini con la tua lista di database e modalità di pooling, poi indirizza l’app su PgBouncer alla porta 6432.

Sì, lo saprai quando ne avrai bisogno.

Effettuare La Chiamata Finale

Il divario di costo è abbastanza reale da giustificare un confronto con la tua bolletta. Ma la configurazione non è la parte difficile.

La parte difficile è il lavoro operativo per cui la fattura gestita stava pagando. Backup, esercitazioni di ripristino, patching e monitoraggio.

Comunque sia, fai un respiro profondo prima di aprire la prossima fattura.

Domande Frequenti Sul PostgreSQL Su Un VPS

Quanta RAM richiede PostgreSQL su un VPS?

PostgreSQL funziona con 1 o 2 GB per carichi di lavoro ridotti e comodamente con 4 GB per la maggior parte delle basi di dati delle applicazioni di produzione. Dataset più pesanti, connessioni contemporanee maggiori o carichi di lavoro analitici spingono il requisito a 8 GB o più.

Posso eseguire PostgreSQL su un VPS da 2 GB?

Sì, puoi eseguire PostgreSQL su un VPS da 2 GB per piccole app, ambienti di sviluppo e progetti secondari a basso traffico. Una scatola da 2 GB lascia poco margine per la cache, quindi le prestazioni delle query diminuiscono man mano che i tuoi dati superano la memoria. Per carichi di lavoro di produzione, 4 GB è la base più sicura.

È più economico ospitare autonomamente PostgreSQL su un VPS rispetto a RDS o Supabase?

Sì, ospitare autonomamente PostgreSQL su un VPS è più economico rispetto a RDS o Supabase per la maggior parte dei carichi di lavoro stabili. Un VPS da 4 GB funziona comunemente a una frazione del costo equivalente di RDS, Supabase Pro o Neon Scale una volta considerati lo storage, i backup e l’uscita dati. Il compromesso è che devi gestire tu stesso il database.

Come posso esporre PostgreSQL su un VPS in modo sicuro?

Non esporre la porta 5432 a Internet pubblico. Associa PostgreSQL a localhost o un IP privato, richiedi l’autenticazione scram-sha-256 e usa tunnel SSH per gli strumenti di amministrazione anziché aprire la 5432 al tuo laptop. La 5432 pubblica con autenticazione debole è un bersaglio noto per i criptominer.

Devo usare Docker per PostgreSQL su un VPS?

No, Docker non è richiesto. Il repository apt ufficiale di PGDG installa PostgreSQL come un servizio di sistema nativo, che è la configurazione più semplice per un ambiente di produzione. Docker è ragionevole se stai già eseguendo altri container.

Come faccio il backup di PostgreSQL su un VPS?

Esegui pg_dump –format=custom su una programmazione cron giornaliera e memorizza l’output su uno storage di oggetti compatibile con S3 fuori dal VPS. Utilizza pg_basebackup più l’archiviazione WAL per il recupero a un punto temporale specifico quando sono cruciali secondi di perdita di dati. Test di ripristino mensile.

Quale piano dovrei scegliere per l’auto-hosting di PostgreSQL su DreamHost?

Il piano VPS Stack 4 di DreamHost (4 GB di RAM) è la base consigliata per la maggior parte dei database di applicazioni in produzione. Scegli Stack 8 (8 GB) per dataset più grandi o alta concorrenza, e Stack 16 per Postgres insieme ad altri servizi che richiedono molte risorse.

Dovrei usare PgBouncer con PostgreSQL su un piccolo VPS?

La maggior parte delle app su un VPS da 4 GB non necessita di PgBouncer all’inizio. Aggiungi un connection pooler quando le connessioni contemporanee si avvicinano a 100, o quando la tua app apre una nuova connessione per ogni richiesta.