PostgreSQL gestito vs self-hosted per piccoli team: compromessi

Cosa si sta davvero scegliendo

Quando si parla di “PostgreSQL gestito”, di solito si intende un servizio cloud che esegue PostgreSQL per te e gestisce i lavori di routine. “PostgreSQL self-hosted” significa che lo esegui tu su una VM, bare metal o container, e la tua squadra si occupa di tutto ciò che gli sta intorno.

La differenza principale non è PostgreSQL in sé. È il lavoro operativo che lo circonda e cosa succede alle 2 di notte quando qualcosa si rompe. Per le piccole squadre, quel gap operativo cambia il rischio. Se nessuno ha esperienza profonda nelle operazioni database, lo stesso problema può passare da “seccatura” a “outage di produzione” molto in fretta.

Managed vs self-hosted PostgreSQL è davvero una decisione sulla proprietà delle responsabilità:

• Backup e ripristini (e dimostrare che funzionano)
• Aggiornamenti e patch di sicurezza
• Monitoraggio delle prestazioni, della crescita dello storage e dei limiti di connessione
• Responsabilità on-call quando la latenza impazzisce o il database non si avvia

Quest'ultimo punto può sembrare drammatico, ma è pratico. In un setup gestito, un provider automatizza molte attività e spesso fornisce supporto e runbook. In un setup self-hosted ottieni più controllo, ma erediti anche tutte le difficoltà: dischi che si riempiono, modifiche di configurazione errate, aggiornamenti falliti, VM "noisy neighbor" e avvisi dimenticati.

Una scelta sbagliata di solito si manifesta in modi prevedibili. Le squadre o perdono ore per outage evitabili perché nessuno ha una procedura di restore pratica, o convivono con query lente perché non c'è tempo per profilare e ottimizzare. I setup gestiti possono sorprenderti con bollette alte se storage e I/O crescono o aggiungi repliche nel panico. Il self-hosting può sembrare economico finché non conti la sorveglianza continua.

Esempio: un team di 4 persone costruisce un'app operativa interna su una piattaforma no-code come AppMaster, usando PostgreSQL per il modello dati. Se il team vuole concentrarsi sui workflow e sulle funzionalità, un database gestito spesso riduce i “giorni di ops” mensili. Se il team ha esigenze di controllo stringenti (estensioni custom, networking particolare, limiti di costo rigidi), il self-hosting può adattarsi meglio, ma solo se qualcuno lo possiede veramente end-to-end.

Backup e ripristino: la parte che la gente dimentica di testare

I backup non sono una casella da spuntare. Sono una promessa che dopo un errore o un outage puoi recuperare i dati abbastanza velocemente e sufficientemente recenti per mantenere il business in funzione. Nella decisione tra managed e self-hosted PostgreSQL, qui è dove le piccole squadre spesso sentono la differenza maggiore.

La maggior parte delle squadre ha bisogno di tre livelli:

• Backup automatici schedulati per sicurezza di base
• Snapshot manuali prima di cambi rischiosi (come aggiornamenti di schema)
• Point-in-time recovery (PITR) per ripristinare a un momento specifico, per esempio subito prima che qualcuno eseguisse un delete sbagliato

Due termini aiutano a fissare le aspettative:

RPO (Recovery Point Objective) è quanto dato puoi permetterti di perdere. Se il tuo RPO è 15 minuti, ti servono backup e log che permettano un ripristino con al massimo 15 minuti di dati mancanti.

RTO (Recovery Time Objective) è quanto tempo puoi permetterti di essere giù. Se il tuo RTO è 1 ora, il processo di ripristino deve essere praticato e prevedibile per rispettarlo.

I test di ripristino sono ciò che viene saltato. Molte squadre scoprono troppo tardi che i backup esistono, ma sono incompleti, troppo lenti da ripristinare o impossibili da usare perché manca la chiave giusta o i permessi.

Con il self-hosting, il lavoro nascosto emerge rapidamente: regole di retention (quanti giorni di backup conservi), crittografia a riposo e in transito, controlli di accesso e dove vivono credenziali e chiavi. I servizi gestiti spesso forniscono dei valori di default, ma devi comunque verificare che corrispondano a RPO, RTO e requisiti di compliance.

Prima di scegliere, assicurati di poter rispondere chiaramente a queste domande:

• Come eseguo un ripristino completo e quanto tempo richiede di solito?
• Supportate PITR e qual è la granularità minima di ripristino?
• Quali sono le impostazioni di retention e crittografia di default, e posso cambiarle?
• Chi può accedere ai backup e avviare i ripristini, e come viene auditato?
• Come testiamo i ripristini regolarmente senza interrompere la produzione?

Un'abitudine semplice aiuta: programma un drill di ripristino trimestrale in un ambiente temporaneo. Anche se la tua app è costruita con strumenti come AppMaster e PostgreSQL sta dietro le quinte, quel drill è ciò che trasforma “abbiamo backup” in vera fiducia.

Aggiornamenti e patch: chi si fa carico dell'onere operativo

Gli aggiornamenti sembrano semplici finché non ricordi cosa toccano: il motore del database, le estensioni, i driver client, i backup, il monitoring e talvolta il codice applicativo. Per le squadre senza un DBA dedicato, la vera domanda non è “possiamo aggiornare?” ma “chi lo rende sicuro e chi viene chiamato se non lo è?”.

Aggiornamenti minori vs maggiori (perché si percepiscono diversamente)

Gli aggiornamenti minori (per esempio da 16.1 a 16.2) sono per lo più bugfix e patch di sicurezza. Sono generalmente a basso rischio, ma richiedono comunque un riavvio e possono rompere qualcosa se dipendi da un comportamento specifico di un'estensione.

Gli aggiornamenti maggiori (per esempio da 15 a 16) sono differenti. Possono cambiare i piani di esecuzione delle query, deprecare funzionalità e richiedere passi di migrazione. Anche quando lo strumento di upgrade funziona, vuoi comunque tempo per validare le prestazioni e verificare la compatibilità con estensioni e ORM.

Patch di sicurezza: urgenza e programmazione

Le patch di sicurezza non aspettano il tuo sprint. Quando esce una vulnerabilità critica in Postgres o OpenSSL, qualcuno deve decidere se patchare stanotte o accettare il rischio fino a una finestra programmata.

Con un servizio gestito, le patch sono in gran parte gestite per te, ma potresti avere controllo limitato sul timing esatto. Alcuni provider ti permettono di scegliere una finestra di manutenzione; altri applicano aggiornamenti con breve preavviso.

Il self-hosting dà controllo totale, ma possiedi anche il calendario. Qualcuno deve monitorare gli avvisi, decidere la gravità, programmare downtime e confermare che la patch sia applicata su primary e repliche.

Se ti autohosti, aggiornamenti sicuri di solito richiedono alcuni non negoziabili: un ambiente di staging vicino alla produzione, un piano di rollback che consideri i dati (non solo i binari), controlli di compatibilità per estensioni e driver e una prova pratica per stimare il downtime. Dopo, serve una breve checklist di verifica: replica, backup e prestazioni delle query.

Pianificare attorno a orari di lavoro e rilasci

Gli aggiornamenti più sicuri sono quelli che gli utenti non notano. Per le piccole squadre, significa allineare il lavoro sul database con il ritmo dei rilasci. Evita di aggiornare lo stesso giorno di un lancio importante. Scegli una finestra con basso carico di supporto e assicurati che qualcuno sia disponibile dopo per osservare le metriche.

Un esempio pratico: se distribuisci uno strumento interno basato su PostgreSQL (per esempio generato e ospitato come parte di un'app AppMaster), un upgrade maggiore non è solo “lavoro DB”. Può cambiare come le tue API si comportano sotto carico. Pianifica un rilascio tranquillo, testa su una copia di produzione e conserva un chiaro punto di stop/go prima di toccare il database live.

I servizi gestiti riducono il lavoro manuale. Il self-hosting ti lascia il volante. Il carico operativo è la differenza reale.

Tuning delle prestazioni e controllo: libertà vs binari di sicurezza

Le prestazioni sono dove managed e self-hosted PostgreSQL possono sembrare più diversi. Su un servizio gestito ottieni solitamente impostazioni sicure di default, dashboard e alcune leve di tuning. In self-hosted puoi cambiare quasi tutto, ma ne assumi anche tutte le conseguenze.

Cosa puoi e non puoi cambiare

I provider gestiti spesso limitano l'accesso superuser, alcuni flag del server e impostazioni a basso livello del file system. Potresti poter regolare parametri comuni (memoria, limiti di connessione, logging), ma non tutto. Le estensioni possono essere un discrimine: molte popolari sono disponibili, ma se ti serve un'estensione di nicchia o una build custom, di solito l'unica opzione è self-hosting.

La maggior parte delle piccole squadre non ha bisogno di flag esotici. Serve il minimo per restare sani: buoni indici, comportamento di autovacuum stabile e connessioni prevedibili.

Il lavoro di tuning che conta davvero

La maggior parte dei guadagni di prestazioni in PostgreSQL deriva da lavoro ripetibile e noioso:

• Indicizza le query che esegui ogni giorno (soprattutto filtri e join)
• Monitora autovacuum e bloat delle tabelle prima che diventino un outage
• Imposta limiti di connessione realistici e usa pooling quando serve
• Dimensiona correttamente la memoria ed evita scan inutili di tabelle grandi
• Rivedi le query lente dopo ogni rilascio, non solo quando gli utenti si lamentano

Il “controllo totale” può essere una trappola quando nessuno sa cosa farà una modifica sotto carico. È facile aumentare le connessioni, disabilitare impostazioni di sicurezza o “ottimizzare” la memoria e ritrovarsi con timeout e crash casuali. I servizi gestiti aggiungono binari di sicurezza: perdi un po’ di libertà, ma riduci anche i modi in cui puoi danneggiare la produzione.

Per rendere il tuning gestibile, trattalo come manutenzione routinaria anziché un’impresa eroica. Al minimo, dovresti poter vedere pressione su CPU e memoria, I/O disco e crescita dello storage, conteggi di connessione e attese/lock, query lente e loro frequenza, e tassi di errore (timeout, deadlock).

Esempio: una piccola squadra lancia un nuovo portale clienti e le pagine diventano più lente. Con un monitoraggio base delle query lente, individuano una chiamata API che fa uno scan di tabella. Aggiungere un indice risolve il problema in minuti. Senza visibilità, potrebbero ipotizzare, scalare il server e restare comunque lenti. L'osservabilità spesso conta più di avere ogni singola leva di controllo.

Sicurezza e compliance di base per piccole squadre

Per le piccole squadre, la sicurezza è meno una questione di strumenti sofisticati e più di fondamentali fatti bene ogni volta. Sia che tu scelga managed o self-hosted PostgreSQL, la maggior parte degli incidenti deriva da errori semplici: un database raggiungibile da internet, un account con privilegi eccessivi o una password leak che non viene mai ruotata.

Inizia dall'hardening. Il tuo database dovrebbe stare dietro regole di rete strette (rete privata quando possibile, o una allowlist rigida). Usa TLS affinché credenziali e dati non viaggino in chiaro. Tratta le password del database come segreti di produzione e prevedi la rotazione.

Il controllo degli accessi è dove il principio del least privilege ripaga. Dai a persone e servizi solo ciò che serve e documenta il perché. Un contractor di supporto che deve vedere gli ordini non ha bisogno dei permessi di modifica dello schema.

Una configurazione di accesso semplice che funziona bene:

• Un utente app con solo i permessi necessari (nessun superuser)
• Account admin separati per migrazioni e manutenzione
• Account in sola lettura per analytics e supporto
• Nessun account condiviso e credenziali non persistenti nel codice
• Log abilitati per connessioni ed errori di permesso

I provider gestiti spesso offrono default più sicuri, ma devi comunque verificarli. Controlla se l'accesso pubblico è disattivato di default, se TLS è obbligatorio, come è gestita la crittografia a riposo e quali log di audit e retention ottieni realmente. Le domande di compliance spesso si riducono alle prove: chi ha fatto cosa, quando e da dove.

Il self-hosting ti dà pieno controllo, ma rende anche più facile farti male da solo. Fallimenti comuni includono esporre la porta 5432 al mondo, mantenere credenziali obsolete di ex-dipendenti e ritardare le patch di sicurezza perché nessuno se ne occupa.

Se stai costruendo uno strumento interno su una piattaforma come AppMaster (che comunemente usa PostgreSQL), mantieni la regola semplice: metti al sicuro l'accesso di rete prima, restringi poi i ruoli e infine automatizza la rotazione dei segreti. Questi tre passi evitano la maggior parte dei problemi di sicurezza evitabili.

Affidabilità, failover e aspettative di supporto

L'affidabilità non è solo “99.9% uptime”. È anche cosa succede durante la manutenzione, quanto velocemente ti riprendi da un deploy sbagliato e chi è sveglio quando il database inizia a dare timeout. Per le squadre senza un DBA dedicato, la realtà quotidiana conta più del numero sulla carta.

Managed vs self-hosted PostgreSQL differisce soprattutto su chi si fa carico delle parti difficili: replica, decisioni di failover e risposta agli incidenti.

I servizi gestiti tipicamente includono replica across zone e un percorso di failover automatico. Questo riduce la probabilità che il crash di un singolo server ti metta KO. Tuttavia vale comunque sapere i limiti: il failover può comportare una breve disconnessione, un nuovo primary con dati leggermente "stale" o un'app che deve ritentare la connessione correttamente. Anche le finestre di manutenzione contano, perché le patch possono ancora innescare riavvii.

Con PostgreSQL self-hosted, l'alta disponibilità è qualcosa che progetti, testi e mantieni sano. Puoi raggiungere forte affidabilità, ma paghi in tempo e attenzione. Qualcuno deve impostare la replica, definire il comportamento di failover e impedire che il sistema deraghi.

Il lavoro continuo include solitamente monitoraggio e alerting (disco, memoria, query lente, lag di replica), drill regolari di failover (per provarlo), mantenere le repliche sane e sostituire nodi guasti, documentare runbook così gli incidenti non dipendono da una persona sola e copertura on-call anche se informale.

Il disaster recovery è distinto dal failover. Il failover copre un problema di nodo o zona. Il disaster recovery copre eventi più grandi: migrazioni sbagliate, dati cancellati o outage a livello di regione. Multi-zone è spesso sufficiente per le piccole squadre. Cross-region può avere senso per prodotti critici per il fatturato, ma aggiunge costi, complessità e può aumentare la latenza.

Le aspettative di supporto cambiano anche. Con PostgreSQL gestito di solito hai supporto via ticket e responsabilità chiara per lo strato infrastrutturale. In self-hosted, il supporto sei tu: log, perdita di pacchetti, problemi disco, aggiornamenti kernel e debugging a mezzanotte. Se il team prodotto è anche il team ops, sii onesto sul carico.

Esempio: una piccola SaaS fa lanci marketing settimanali. Un outage di 10 minuti durante un lancio è una perdita di business reale. Un setup gestito con failover multi-zone più un'app che ritenta le connessioni può essere il modo più semplice per raggiungere quell'obiettivo. Se stai costruendo strumenti interni (per esempio su AppMaster, dove la tua app dipende comunque da PostgreSQL), la stessa domanda vale: quanto downtime può tollerare il business e chi lo risolve quando accade?

Costo totale di proprietà: cosa contare oltre la fattura

Quando la gente confronta managed vs self-hosted PostgreSQL, spesso paragona il prezzo mensile e si ferma lì. Una domanda migliore è: quanto costa al tuo team mantenere il database sicuro, veloce e disponibile mentre continui a rilasciare prodotto?

Inizia con le voci ovvie. Pagherai per compute e storage in entrambi i casi, oltre a I/O, backup e talvolta egress di rete (per esempio quando ripristini da uno snapshot o sposti dati tra regioni). I piani gestiti possono sembrare economici finché non aggiungi storage extra, repliche di lettura, tier IOPS superiori o retention di backup più lunga.

Poi aggiungi i costi che non compaiono in fattura. Se non hai un DBA dedicato, la spesa più grande è spesso il tempo delle persone: essere on-call, cambiare contesto durante gli incidenti, debuggare query lente invece di costruire funzionalità e il costo di business dei downtime. Il self-hosting spesso aumenta questo overhead perché possiedi anche HA, monitoring, log e capacità di failover di riserva.

Costi “sorpresa” comuni da verificare:

• Managed: addebiti per burst I/O, costo per repliche across zone, storage che cresce senza controllo, tier di supporto premium
• Self-hosted: tool e test per HA, manutenzione dello stack di monitoring, tempo per patch di sicurezza, nodi extra per il failover che stanno per lo più inattivi

Un modo semplice per stimare il TCO mensile è essere espliciti sul tempo:

• Infrastruttura: compute + storage + backup + egress previsto
• Buffer di rischio: aggiungi 10%–30% per picchi (traffic, crescita storage, ripristini)
• Tempo persone: ore al mese (on-call, patch, tuning) x costo orario caricato
• Costo outage: ore di downtime previste x costo orario per il business

Esempio: un team prodotto di tre persone esegue un piccolo database managed a $250/mese. Se continuano a perdere 6 ore/mese per query lente e manutenzione (6 x $80 = $480), il costo reale mensile sale a circa $730, prima degli outage. Se self-hostano e quel tempo raddoppia perché gestiscono anche HA e monitoring, l'opzione “più economica” può diventare rapidamente la più costosa.

Se costruisci app su una piattaforma come AppMaster, considera quanto lavoro database è davvero personalizzato. Meno tempo il team spende sul plumbing, più quei costi indiretti emergono e più diventano preziose operazioni prevedibili.

Come decidere in 5 passi (senza un DBA)

Se sei una piccola squadra, decidere tra managed e self-hosted PostgreSQL è meno una questione di preferenze e più di chi gestirà i problemi alle 2 di notte.

1) Scrivi i tuoi non negoziabili

Elenca i vincoli che non puoi violare: downtime accettabile, crescita dei dati, requisiti di compliance e un tetto di budget mensile (includendo il tempo delle persone, non solo l'hosting).

2) Definisci il recupero in una frase

Scrivi un singolo obiettivo che copra perdita dati e downtime. Esempio: “Possiamo perdere fino a 15 minuti di dati e dobbiamo tornare online entro 1 ora.”

3) Decidi come avverranno gli aggiornamenti

Gli aggiornamenti sono facili da rimandare finché non diventa impossibile. Scegli una policy che puoi mantenere. Nomina un proprietario (una persona, non “il team”), decidi con quale frequenza applicare patch minori, quando prevedi aggiornamenti maggiori, dove testare prima e come fare rollback se qualcosa si rompe.

Se non puoi rispondere con sicurezza, l'hosting gestito di solito abbassa il rischio.

4) Sii onesto su quanto controllo ti serve davvero

Le squadre spesso dicono di volere “controllo totale” quando in realtà desiderano “qualche funzionalità specifica”. Chiediti se hai davvero bisogno di estensioni specifiche, impostazioni insolite, accesso al livello OS o agenti di monitoraggio custom. Se la risposta è “forse un giorno”, trattalo come nice-to-have.

5) Scegli un modello operativo e assegna proprietari

Scegli managed (il provider gestisce la maggior parte delle operazioni), self-hosted (lo gestite tutto voi) o ibrido (database gestito, app self-hosted). L'ibrido è comune per le piccole squadre perché mantiene il controllo dove conta riducendo lo sforzo sul database.

Uno scenario rapido: un team di 4 persone che costruisce uno strumento interno potrebbe andare bene con self-hosting all'inizio, poi pentirsene quando un disco si riempie in una settimana intensa. Se la stessa squadra costruisce con AppMaster e distribuisce app sul cloud, abbinare quel flusso a PostgreSQL gestito può mantenere il focus sulle funzionalità, permettendo comunque di migrare dopo se i requisiti cambiano.

La decisione è giusta quando il carico on-call corrisponde alla dimensione del team e i tuoi obiettivi di recupero sono realistici, scritti e assegnati.

Errori comuni che creano dolore dopo

La maggior parte delle squadre non brucia per la scelta managed vs self-hosted. Si brucia perché assume che le parti noiose si sistemino da sole.

Un esempio classico: una squadra rilascia un portale clienti, attiva i backup automatici e si sente al sicuro. Mesi dopo, qualcuno cancella una tabella durante una correzione notturna. I backup esistono, ma nessuno conosce i passaggi esatti per il ripristino, quanto tempo richiede o quali dati mancheranno.

Gli errori che si manifestano nei momenti peggiori:

• Backup considerati “attivi” invece che “provati”. Esegui drill di ripristino regolari. Cronometra, conferma il login e verifica i record chiave. Se usi PITR, testalo anche.
• Aggiornamenti eseguiti direttamente in produzione. Anche gli aggiornamenti minori possono far emergere problemi di estensioni, cambi di configurazione o sorprese sulle query. Prova in staging con dati simili a quelli di produzione e scrivi un piano di rollback.
• Tuning fatto troppo presto e nell'ordine sbagliato. Ottieni più guadagni correggendo query lente, aggiungendo l'indice giusto o riducendo query chatty prima di toccare impostazioni profonde.
• Gestione delle connessioni ignorata. Le app moderne creano molte connessioni brevi (web, worker, job in background). Senza pooling puoi colpire il limite di connessioni e ottenere timeout casuali sotto carico.
• Nessuna ownership chiara. “Tutti sono responsabili del database” spesso significa che nessuno risponde, nessuno approva cambi rischiosi e nessuno aggiorna i runbook.

Se vuoi una sola abitudine che prevenga la maggior parte degli incidenti, annota tre cose: chi è on-call per il database, come ripristinare su una nuova istanza e come funziona la pianificazione degli aggiornamenti (incluso chi firma il via libera).

Anche se costruisci con una piattaforma no-code come AppMaster e PostgreSQL sta dietro le quinte, questi errori contano. La tua app può essere pronta per la produzione, ma servono comunque ripristini testati, un processo di aggiornamento calmo e un piano per connessioni e responsabilità.

Controlli rapidi, un esempio realistico e prossimi passi

Mantieni la decisione ancorata a pochi controlli che puoi rispondere in 15 minuti. Rivelano il rischio rapidamente, anche se nessuno nel team è uno specialista database.

Controlli rapidi che puoi fare oggi

Inizia con backup e controlli di accesso. Scrivi le risposte dove tutto il team le può trovare.

• Quando è stato l'ultimo test di ripristino e ha ripristinato con successo in un nuovo ambiente?
• Qual è la retention (per esempio 7, 30, 90 giorni) e corrisponde alle tue esigenze?
• Chi può cancellare backup o cambiare la retention e quell'accesso è limitato?
• Dove sono conservati i backup e sono crittografati?
• Qual è il tuo target RPO/RTO (quanti dati puoi perdere e quanto velocemente devi tornare online)?

Poi guarda aggiornamenti e monitoraggio. Le piccole squadre vengono fatte male da “lo faremo più tardi” più che dall'aggiornamento in sé.

• Qual è la tua cadenza di aggiornamento (patch mensili, revisioni trimestrali) e chi ne è responsabile?
• Hai una finestra di manutenzione accettata dal business?
• Riesci a vedere chiaramente la versione corrente di Postgres e le prossime EOL?
• Hai alert per crescita disco, picchi CPU e backup falliti?
• Riesci a individuare query lente (anche una semplice vista delle 5 più lente)?

Un controllo di abitudine: se lo storage cresce del 10% al mese, sai quando raggiungerai il limite? Metti un promemoria sul calendario prima di scoprirlo a modo duro.

Un esempio realistico per una squadra di 5 persone

Un team di 5 persone costruisce uno strumento interno per supporto e operazioni. Parte con poche tabelle, poi cresce in ticket, allegati, log di audit e import giornalieri. Dopo tre mesi il database è 5x più grande. Un lunedì, una modifica di schema rallenta una schermata chiave e qualcuno chiede: “Possiamo rollbackare?” Il team capisce di avere backup, ma non ha mai testato un ripristino e non sa quanto tempo richiederebbe.

Prossimi passi

Scegli l'opzione più semplice che soddisfa il tuo RPO/RTO e la capacità del team di gestirla ogni settimana, non “un giorno”. Mantieni lo stack flessibile così puoi spostarti in seguito senza riscrivere tutto.

Se costruisci con AppMaster, può essere utile separare la delivery dell'app dalle operazioni sul database: puoi modellare i dati in PostgreSQL, generare backend pronti per la produzione oltre a web e app mobile, e distribuire su AppMaster Cloud o sui principali cloud. Questo rende “dove gira Postgres” più una decisione operativa che una riscrittura. Per ulteriori informazioni sulla piattaforma, AppMaster è disponibile su appmaster.io.