PostgreSQL vs CockroachDB per la disponibilità multi-regione

Quale problema stai davvero cercando di risolvere?

"Disponibilità multi-regione" viene usato per indicare obiettivi diversi. Mischiarli è il motivo per cui i team scelgono il database sbagliato.

Prima di confrontare PostgreSQL e CockroachDB, annota (1) quale failure specifico vuoi sopravvivere e (2) cosa gli utenti devono vedere mentre quel failure è in corso.

La maggior parte dei team persegue una combinazione di:

• Maggiore uptime quando una regione va giù (failover)
• Risposte più veloci per utenti lontani dalla regione principale (minore latenza)
• Regole sui dati legate alla geografia (località o residenza)
• Comportamento prevedibile sotto carico, non solo nei test in condizioni ideali

L'obiettivo condiviso è semplice: un cliente su un altro continente dovrebbe comunque ottenere risultati veloci e corretti.

La parte difficile è che «veloce» e «corretto» possono entrare in conflitto quando distribuisci le scritture tra regioni. Una consistenza più forte di solito richiede più coordinazione cross-region, e questo aggiunge latenza. Ridurre la latenza spesso significa leggere da una copia vicina o usare replicazione asincrona, cosa che può generare letture stale o conflitti che dovrai gestire tu.

Un esempio concreto: un utente in Germania aggiorna l'indirizzo di spedizione e subito dopo completa l'ordine. Se il checkout legge da una replica negli USA che è indietro di qualche secondo, l'ordine può usare il vecchio indirizzo. Alcuni prodotti possono tollerarlo con una UX chiara e retry. Altri (pagamenti, inventario, conformità) no.

Non esiste una scelta universalmente migliore. La risposta giusta dipende da cosa non deve mai sbagliare, cosa può essere un po' più lenta e quanta complessità operativa il tuo team è disposto a gestire ogni giorno.

Due approcci a “disponibile in più regioni"

Quando si confrontano PostgreSQL e CockroachDB per l'uso multi-regione, spesso si stanno confrontando due progetti diversi.

Con PostgreSQL, la configurazione più comune è con primaria singola. Una regione è la "casa" dove avvengono le scritture. Altre regioni eseguono repliche di lettura che copiano le modifiche dal primario. Se la regione primaria fallisce, promuovi una replica altrove e punti l'app a quella. Fatto bene, può funzionare ottimamente, ma il sistema è comunque organizzato attorno a un unico luogo di scrittura e a un piano di failover deliberato.

Con sistemi SQL distribuiti come CockroachDB, il database è progettato per distribuire dati e responsabilità tra le regioni fin dall'inizio. I dati sono copiati su più nodi e il cluster concorda l'ordine delle scritture. Puoi spesso collocare certi dati più vicini agli utenti in regioni diverse mantenendo un unico database logico.

Il cambiamento per il team applicativo riguarda meno la sintassi SQL e più le aspettative:

• Writes: le scritture su PostgreSQL sono più veloci vicino al primario. Le scritture su CockroachDB spesso richiedono l'accordo di più repliche, il che può includere conferme cross-region.
• Reads: PostgreSQL può servire letture locali dalle repliche (con un compromesso sulla freschezza). CockroachDB può servire letture consistenti, ma può pagare un costo di coordinazione a seconda di come sono posizionati i dati.
• Failures: il failover in PostgreSQL è un interruttore che devi scatenare e gestire. CockroachDB è costruito per continuare a funzionare attraverso alcuni failure regionali, ma solo nei limiti delle sue regole di replicazione e quorum.

Il requisito nascosto è la correttezza durante i failure. Se puoi tollerare letture brevemente stale o una breve pausa sulle scritture durante il failover, PostgreSQL con primaria singola può essere una valida scelta. Se hai bisogno che il sistema resti corretto e scrivibile mentre una regione è down, allora accetti il costo di coordinazione di un database distribuito.

Garanzie di consistenza: su cosa puoi contare

Consistenza, in termini semplici: quando qualcuno aggiorna un record, tutti gli altri dovrebbero vedere la stessa verità.

Con PostgreSQL, la consistenza forte è più semplice quando l'app parla con un solo database primario. Letture e scritture avvengono nello stesso posto, quindi le transazioni si comportano in modo prevedibile. Puoi aggiungere repliche per velocizzare le letture in altre regioni, ma allora devi decidere quando è accettabile leggere dati leggermente obsoleti.

Con CockroachDB e altri sistemi SQL distribuiti, la consistenza forte è possibile, ma diventa più costosa man mano che distribuisci i dati su regioni lontane. Le scritture che devono essere consistenti tra regioni richiedono coordinazione tra nodi. Più distanti sono le regioni, più lento sarà quel coordinamento. Lo sentirai spesso come scritture e transazioni più lente, specialmente quando una transazione tocca righe che risiedono in regioni diverse.

Entrambi i sistemi possono supportare transazioni serializzabili (il database lavora per far sembrare le modifiche concorrenti come se fossero avvenute una alla volta). La differenza è dove avviene il lavoro: PostgreSQL paga la maggior parte del costo dentro una singola regione, mentre un sistema distribuito può pagarne la parte tra regioni.

Alcune domande che rendono concreti i trade-off:

• Gli utenti possono mai vedere letture stale, anche per pochi secondi?
• Due regioni possono accettare scritture indipendenti, o ogni scrittura deve essere concordata globalmente?
• Cosa succede se due persone modificano lo stesso record nello stesso momento? Permetti conflitti?
• Quali azioni devono essere corrette sempre (pagamenti, permessi) vs "alla fine ok" (analytics)?
• Hai bisogno di una verità globale, o una "verità locale" è accettabile per alcuni dati?

Aspettative di latenza: cosa sentiranno gli utenti

Un modello mentale utile: la distanza aggiunge tempo, e la coordinazione aggiunge altro tempo. La distanza è fisica. La coordinazione è il database che aspetta altri nodi prima di poter dichiarare "fatto".

Con una configurazione PostgreSQL in una singola regione, la maggior parte del lavoro avviene vicino. Letture e scritture completano di solito in un solo round trip dall'app al database. Se metti una replica di lettura in un'altra regione, le letture possono essere locali, ma le scritture vanno sempre al primario e le repliche sono sempre in ritardo di almeno una certa quantità.

In un sistema distribuito come CockroachDB, i dati sono sparsi tra le regioni. Questo può rendere alcune letture veloci quando i dati necessari sono locali. Ma molte scritture devono essere confermate da una maggioranza di repliche. Se i tuoi dati sono replicati tra continenti, anche una semplice scrittura può richiedere ack cross-region.

Non giudicare dalla latenza media. Guarda la latenza p95 (i peggiori 5% delle richieste). Gli utenti notano quelle pause. Una pagina che normalmente si carica in 120 ms ma raggiunge 800 ms qualche volta al giorno sembra instabile, anche se la media è accettabile.

Cosa significa "veloce" dipende dal tuo workload. Le app scrittura-intensive sentono di più il costo della coordinazione. Le app lettura-intensive possono cavarsela bene se le letture sono locali. Transazioni più grandi, workflow multi-step e righe "hot" (molti utenti che aggiornano lo stesso record) amplificano la latenza.

Quando valuti PostgreSQL vs CockroachDB, mappa le tue azioni utente principali (signup, checkout, ricerca, aggiornamenti admin) a dove stanno i dati e a quante regioni devono concordare su ogni transazione. Quell'esercizio predice cosa sentiranno gli utenti meglio di benchmark generici.

Compromessi operativi: cosa gestirai quotidianamente

Le feature list contano meno di ciò che ti sveglia alle 2 di notte e di cosa il tuo team deve fare ogni settimana.

Le operazioni su PostgreSQL sono familiari e prevedibili. Multi-regione di solito significa che gestisci anche componenti di supporto: repliche, tooling per il failover o cluster regionali separati con routing applicativo. Il lavoro spesso sta nel dimostrare che il piano funziona (prove di failover, restore) più che nell'ottimizzazione quotidiana delle query.

CockroachDB sposta più della storia multi-regione dentro il database stesso. Questo può ridurre il numero di componenti esterni, ma significa anche che devi comprendere un sistema distribuito: salute dei nodi, replicazione, rebalancing e cosa fa il cluster sotto stress.

In pratica, i team finiscono per svolgere le stesse attività di base in entrambi i setup:

• Pianificare upgrade e validare driver, monitoring e automazione
• Prendere backup e testare i restore (non solo verificare che i backup esistano)
• Eseguire prove di failover e documentare i runbook esatti
• Investigare query lente e separare "query cattiva" dalla latenza cross-region
• Monitorare la crescita dello storage e il comportamento di compaction a lungo termine

I failure mode si sentono diversi. Con PostgreSQL, un outage di regione spesso innesca un failover deliberato. Puoi accettare un periodo di sola lettura, latenza elevata o funzionalità ridotta. In un database distribuito, il caso più difficile è spesso lo split di rete. Il sistema può proteggere la consistenza rifiutando alcune scritture finché non è disponibile il quorum.

Anche l'osservabilità cambia. Con un primario singolo ti chiedi principalmente: "Perché questa query è lenta?" Con un cluster distribuito ti chiedi anche: "Dove sono finiti questi dati e perché la query ha attraversato regioni?"

I costi aumentano in modi ovvi e non ovvi. Aggiungere una seconda regione può incrementare il numero di nodi, ma aumenta anche il monitoring, la complessità degli incidenti e il tempo passato a spiegare latenza e comportamento di failure ai team di prodotto.

Cambiamenti di schema e migrazioni in un setup distribuito

Una modifica di schema è qualsiasi aggiornamento alla forma dei tuoi dati: aggiungere una colonna per un flag di feature, rinominare un campo, cambiare un tipo (int a string), aggiungere un indice o introdurre una nuova tabella.

In PostgreSQL, le migrazioni possono essere veloci, ma il rischio è spesso il tempo di lock e il blocco delle scritture. Alcune modifiche riscrivono un'intera tabella o tengono lock più a lungo del previsto, trasformando un deploy normale in un incidente se avviene a picco traffico.

In un database distribuito, il rischio si sposta. Anche quando le modifiche online sono supportate, il cambiamento deve comunque essere concordato tra i nodi e replicato tra le regioni. Le modifiche “semplici” possono richiedere più tempo per essere rollate e più tempo per essere validate. Potresti finire il deploy e passare comunque tempo a osservare lag, hotspot e sorprese nei piani di query in ogni regione.

Alcune buone pratiche per mantenere le migrazioni noiose:

• Preferisci prima modifiche additive (nuova colonna, nuova tabella). Cambia letture e scritture dopo. Rimuovi i vecchi campi più tardi.
• Mantieni ogni migration sufficientemente piccola da poter essere rollbackata rapidamente.
• Evita di cambiare i tipi in place quando possibile. Backfilla in una nuova colonna.
• Tratta gli indici come un rollout di feature, non come una modifica veloce.
• Esegui le migrazioni con dimensioni di dati realistiche, non su database di test vuoti.

Esempio: aggiungi preferred_language per gli utenti EU. Aggiungi la colonna, scrivi sia nei campi vecchi sia in quelli nuovi per una release, poi aggiorna l'UI per leggere il nuovo campo e solo dopo pulisci. Nei setup multi-regione, rollout a tappe riduce le sorprese quando le regioni si sincronizzano a velocità diverse.

Il vero costo di distribuire presto

Scegliere tra PostgreSQL e CockroachDB da subito non è solo una decisione sul database. Cambia quanto velocemente rilasci, quante sorprese incontri in produzione e quanto tempo il tuo team spende a mantenere il sistema stabile invece di costruire funzionalità.

Se puoi raggiungere i tuoi obiettivi con una regione primaria, rimanere semplice di solito vince all'inizio. Avrai meno parti in movimento, failure più chiari e debug più veloci. Anche l'assunzione è più semplice perché l'esperienza approfondita su PostgreSQL è comune, e lo sviluppo locale e CI tendono a essere più semplici.

I team spesso restano centralizzati perché facilita iterazione più rapida, rollback più semplici e performance più prevedibili. L'on-call è più facile quando il sistema ha meno componenti in movimento.

Andare distribuiti presto può comunque essere la scelta giusta quando i requisiti sono reali e non negoziabili: target di uptime rigorosi tra regioni, esigenze di residenza dei dati, o una base utenti globale dove la latenza impatta direttamente i ricavi.

La tassa della complessità emerge in piccoli modi che si sommano: il lavoro sulle feature richiede più tempo perché devi considerare il comportamento multi-regione, i test devono coprire più modalità di failure e gli incidenti durano più a lungo perché la causa può essere temporale, replicazione o consenso anziché "il database è giù". Anche le migrazioni di schema richiedono più cautela.

Una regola pratica: convalida prima la domanda, poi distribuisci quando il dolore è misurabile. Trigger comuni sono SLO di uptime mancati in una regione, abbandoni utenti costanti dovuti a latenza o requisiti di compliance che bloccano accordi.

Se stai costruendo con uno strumento come AppMaster, può aiutare partire con un deployment più semplice mentre affini workflow e modelli dati, e poi passare a un piano multi-regione una volta provati prodotto e pattern di traffico.

Un modo passo-passo per scegliere tra i due

"Multi-regione" diventa più chiaro quando lo trasformi in pochi numeri e pochi flussi utente.

Passi consigliati

1. Scrivi RPO e RTO in parole chiare. Esempio: "Se una regione muore, possiamo perdere fino a 1 minuto di dati (RPO) e dobbiamo tornare online in 15 minuti (RTO)." Se non puoi tollerare la perdita di scritture confermate, dillo esplicitamente.
2. Mappa dove sono gli utenti e marca le azioni critiche in scrittura. Elenca le tue regioni e le azioni principali: registrazione, checkout, reset password, pubblicare un commento, visualizzare un feed. Non tutte le scritture sono ugualmente importanti.
3. Imposta i bisogni di consistenza per feature. Pagamenti, inventario e saldi contabili di solito richiedono correttezza stringente. Feed, analytics e "ultimo accesso" spesso accettano piccoli ritardi.
4. Definisci un budget di latenza e testa dalle regioni target. Decidi cosa significa "abbastanza veloce" (per esempio 200–400 ms per azioni chiave), poi misura il round-trip dalle regioni che ti interessano.
5. Scegli un modello operativo che il tuo team può sostenere. Sii onesto su tempo on-call, competenze DB e tolleranza alla complessità.

Un esempio rapido

Se la maggior parte degli utenti è negli USA e solo una piccola parte in EU, potresti mantenere le scritture in una regione primaria, stringere i target di recovery e aggiungere ottimizzazioni di lettura EU per schermate non critiche. Se i flussi EU con molte scritture richiedono una UX migliore, considera un servizio o una coda lato EU in modo che l'interfaccia rimanga responsiva. Rivedi la scelta del database quando la correttezza multi-regione diventa requisito per tabelle core (account, fatturazione, permessi).

Scenario d'esempio: clienti US ed EU sullo stesso prodotto

Immagina un SaaS B2B dove un account ha collaboratori a New York e Berlino. Tutti vedono gli stessi ticket, fatture e limiti di utilizzo. La fatturazione è condivisa, quindi un evento di pagamento dovrebbe influire immediatamente sull'accesso per tutto l'account.

Con PostgreSQL, una configurazione comune è un primario negli USA e repliche di lettura in EU. Gli utenti USA ottengono letture e scritture veloci. Gli utenti EU possono leggere localmente, ma tutto ciò che deve essere corretto in tempo reale (piano corrente, permessi, stato fattura) spesso deve toccare il primario USA. Se le letture EU provengono da una replica, accetti che possano esserci ritardi. Questo può sembrare, per esempio, un amministratore finanziario a Berlino che paga una fattura, aggiorna la pagina e vede ancora "scaduto" per un po'.

Con un database distribuito multi-regione come CockroachDB, puoi posizionare i dati più vicino a entrambe le regioni mantenendo un database logico unico. Il compromesso è che molte scritture e alcune letture devono coordinarsi tra regioni per restare consistenti. Quel round-trip cross-region diventa parte del percorso normale, specialmente per record condivisi come impostazioni account e fatturazione.

Un piano a tappe che spesso funziona:

• Parti con una regione e un primario PostgreSQL, poi misura dove sono realmente gli utenti e le scritture.
• Aggiungi repliche di lettura EU per reporting e schermate non critiche.
• Se flussi EU con molte scritture richiedono UX migliore, considera un livello di servizio EU o una coda per mantenere l'interfaccia reattiva.
• Rivaluta la scelta del database quando le tabelle core richiedono correttezza multi-regione (account, fatturazione, permessi).

Se costruisci su AppMaster, mantenere la logica in processi business visuali può rendere meno dolorose modifiche successive alla strategia di deployment o al database.

Errori comuni che i team fanno

L'errore più grande è presumere che "multi-regione" significhi automaticamente veloce per tutti. Un database distribuito non batte la fisica. Se una transazione deve confermare in due posti lontani, il tempo del round-trip si vede in ogni scrittura.

Un'altra trappola è mescolare aspettative di correttezza senza ammetterlo. I team possono esigere accuratezza rigorosa per saldi, inventario e permessi, ma trattare altre parti dell'app come "abbastanza vicino". Gli utenti vedranno allora un valore su una schermata e un valore diverso nella successiva.

Pattern da tenere d'occhio:

• Aspettarsi che tutte le scritture sembrino locali anche quando richiedono conferme cross-region
• Trattare la consistenza eventuale come un dettaglio UI e scoprire che rompe regole di business (refund, quote, controllo accessi)
• Imparare la realtà operativa solo dopo il primo incidente (backup, upgrade, salute nodi, failure di regione)
• Sottovalutare quanto tempo ci vuole per debugare transazioni lente quando log e dati sono sparsi tra regioni
• Trattare la prima decisione come definitiva invece di pianificare un percorso di evoluzione

Le migrazioni meritano attenzione extra perché tendono a succedere quando il prodotto cresce più in fretta. Una modifica semplice su un nodo singolo può diventare rischiosa se deve restare consistente su molti nodi e regioni.

Tratta la prima scelta del database come un passo, non come destino. Se costruisci con AppMaster, puoi prototipare workflow e modelli dati rapidamente, poi validare latenza reale e comportamenti di failure prima di impegnarti in un setup distribuito complesso.

Checklist rapida prima di impegnarti

Prima di scegliere una direzione, definisci cosa significa "buono" per il tuo prodotto. I setup multi-regione possono risolvere problemi reali, ma impongono scelte continue su latenza, consistenza e operazioni.

Mantieni questa checklist breve e specifica:

• Identifica le 3 azioni utente principali (per es.: login, checkout, aggiornare un record condiviso) e dove sono quegli utenti.
• Decidi cosa deve essere fortemente consistente tra regioni e cosa può tollerare ritardo.
• Scrivi la storia di failure in parole semplici: "Se la regione X è down per 1 ora, gli utenti nella regione Y possono fare A e B, ma non C."
• Assegna responsabilità per backup, test di restore, upgrade e monitoring.
• Prepara un piano di cambiamento di schema che mantenga l'app compatibile durante rollout a tappe.

Se costruisci con una piattaforma no-code come AppMaster, mettere questa checklist nelle note di build aiuta a mantenere allineati modello dati, logica di business e passi di rollout man mano che i requisiti evolvono.

Prossimi passi: testa le ipotesi e scegli un percorso di build

La maggior parte dei team non ha bisogno di un database distribuito dal giorno zero. Hanno bisogno di comportamento prevedibile, operazioni semplici e un modo chiaro di crescere.

Questa decisione spesso si riduce a una domanda: hai davvero bisogno di scritture corrette e attive in più regioni per i workflow core?

• Se puoi mantenere una regione primaria e usare repliche, cache o copie in sola lettura altrove, PostgreSQL è spesso una scelta eccellente.
• Se hai davvero bisogno di scritture multi-regione con consistenza forte, SQL distribuito può andare bene, purché tu accetti latenza di base più alta e maggiore complessità operativa.

Un modo pratico per mettere alla prova la scelta è fare una proof mirata usando workflow reali.

Un piccolo piano di prova (1–2 giorni)

• Misura la latenza p95 da ogni regione che ti interessa (letture e scritture).
• Simula una modalità di failure (kill di un nodo, blocco di una regione o disabilita traffico inter-region) e registra cosa si rompe.
• Esegui 2–3 transazioni critiche end-to-end (signup, checkout, aggiornamento profilo) e osserva retry, timeout ed errori visibili all'utente.
• Prova una modifica di schema che prevedi di fare spesso (aggiungere una colonna, un indice). Cronometrala e nota cosa blocca.

Dopo, scrivi la proprietà dei dati. Quale regione “possiede” un record cliente? Quali tabelle devono essere fortemente consistenti e quali possono essere eventualmente consistenti (per esempio eventi di analytics)? Definisci anche cosa farebbe scattare una migrazione successiva, come eseguirai il backfill e come effettueresti il rollback.

Un percorso comune è partire con PostgreSQL, mantenere lo schema pulito (chiavi primarie chiare, meno hotspot di scrittura cross-table) e progettare in modo che i dati specifici per regione siano più facili da separare in seguito.

Se usi AppMaster, puoi modellare uno schema PostgreSQL nel Data Designer e generare app pronte per la produzione da distribuire sul cloud scelto, mentre valuti se le scritture multi-regione sono davvero necessarie. Se vuoi esplorare questo approccio, AppMaster su appmaster.io è un modo pratico per prototipare l'intero stack (backend, web e mobile) senza impegnarti subito in un'architettura multi-regione complessa.