# Amazon Aurora DSQL: un database SQL distribuito e sempre disponibile
Table of Contents
Tenere un database sempre raggiungibile è uno dei problemi più difficili di chi manda avanti servizi online. Un database è il registro dove un’applicazione conserva i suoi dati: ordini, utenti, pagamenti, catalogo. Se si ferma, si ferma tutto. E se quegli stessi dati vanno letti e aggiornati da più parti del mondo nello stesso momento, tenerli coerenti diventa un rompicapo. Il 27 maggio 2025 AWS ha reso disponibile a tutti - in “disponibilità generale”, cioè fuori dalla fase di anteprima riservata - Amazon Aurora DSQL, un database pensato proprio per questo scenario.
Cos’è Aurora DSQL
Aurora DSQL è un database relazionale: organizza i dati in tabelle con righe e colonne, che si interrogano con il linguaggio SQL, lo stesso usato da decenni per questo tipo di archivi. Ha però due caratteristiche che lo distinguono da un database installato su un server tradizionale.
È serverless. “Senza server” non significa che i server non esistano, ma che non è chi usa il servizio a doverli scegliere, dimensionare, avviare o aggiornare: se ne occupa AWS dietro le quinte. Chi sviluppa vede solo un indirizzo a cui connettersi e paga per quanto lavoro effettivamente fa il database.
È distribuito. I dati non stanno su una sola macchina, ma sono replicati in automatico su più zone di disponibilità (data center vicini ma indipendenti all’interno di una regione) e, se si vuole, su più regioni geografiche diverse.
Un terzo dettaglio conta per chi già lavora con questi strumenti: Aurora DSQL è compatibile con PostgreSQL, uno dei database open source più diffusi. Nella documentazione AWS indica la compatibilità con la versione 16 di PostgreSQL. In pratica ci si collega con i driver, le librerie e gli strumenti che si usano già con PostgreSQL, come il client psql.
Il problema che prova a risolvere
Chi gestisce un database tradizionale conosce a memoria una lista di grattacapi.
Il primo è la manutenzione. Applicare gli aggiornamenti di sicurezza (le cosiddette patch) o passare a una versione nuova spesso richiede una finestra in cui il database è rallentato o fermo. Va pianificata, comunicata, sorvegliata.
Il secondo è il failover, cioè cosa succede quando la macchina principale si guasta. In un’architettura classica esiste una copia pronta a subentrare, ma il passaggio va gestito e non è mai del tutto indolore: c’è un intervallo in cui il servizio arranca, un tempo di fermo che va tenuto sotto la soglia di quanto ci si può permettere di restare fermi, e nei casi peggiori si rischia di perdere gli ultimi dati scritti.
Il terzo è la crescita. Quando i dati o il traffico diventano troppi per una macchina sola, la via classica è lo sharding: spezzare i dati in tanti pezzi (frammenti) distribuiti su più macchine. Funziona, ma complica tutto. L’applicazione deve sapere su quale frammento sta ogni dato, e le operazioni che ne coinvolgono più di uno diventano lente e fragili.
Aurora DSQL nasce per togliere questi tre compiti dalle spalle di chi sviluppa: niente patching manuale, niente failover da orchestrare, niente sharding da progettare a mano.
Alta disponibilità e consistenza forte
Sono due promesse diverse, e vale la pena tenerle separate.
La disponibilità misura per quanto tempo il servizio resta raggiungibile. Di solito si esprime con una percentuale. AWS dichiara per Aurora DSQL una disponibilità del 99,99% in una singola regione e del 99,999% tra più regioni. Tradotto in tempo concreto: 99,99% significa lasciar fuori al massimo circa 52 minuti di disservizio in un anno; 99,999% scende a poco più di 5 minuti l’anno. Sono obiettivi dichiarati dal fornitore, non garanzie che nulla possa mai andare storto, ma danno la misura dell’ordine di grandezza.
Come ci arriva? Con un’architettura che AWS descrive come attiva-attiva. Invece di avere una copia principale che lavora e una di scorta che aspetta, più copie lavorano contemporaneamente e possono accettare sia letture sia scritture. Se un componente si guasta, il traffico viene dirottato in automatico verso quelli sani, senza il failover tradizionale da coordinare. Ogni componente è ridondato su tre zone di disponibilità.
Nella configurazione multi-regione, due cluster in due regioni diverse si presentano all’applicazione come un unico database logico: entrambi gli indirizzi accettano letture e scritture, un assetto che tocca da vicino anche la conformità GDPR quando i dati attraversano più aree geografiche. A fare da arbitro c’è una terza regione con un ruolo ridotto, definita log-only witness (testimone di solo registro), che non serve le richieste ma aiuta a decidere quale sia la versione corretta dei dati in caso di problemi.
La consistenza forte è la seconda promessa, ed è la più delicata. In un sistema distribuito, dopo una scrittura, le varie copie del dato possono impiegare un attimo ad allinearsi. Molti sistemi accettano questo ritardo: si parla di consistenza eventuale, cioè “prima o poi tutte le copie saranno uguali”. Nel frattempo, però, due utenti potrebbero leggere valori diversi. La consistenza forte promette invece che ogni lettura veda sempre l’ultimo dato scritto, anche da un’altra regione. Per un carrello, un saldo o una prenotazione, questa differenza non è un dettaglio: è la differenza tra vendere due volte l’ultimo pezzo di magazzino oppure no. Aurora DSQL offre transazioni ACID (le proprietà che rendono affidabili le operazioni sui database) con consistenza forte anche tra regioni.
Serverless: scala senza sharding e senza patch
Il lato “serverless” si traduce in due comodità pratiche.
La prima è la scalabilità automatica. Aurora DSQL adatta da solo capacità di calcolo, lettura/scrittura e spazio di archiviazione in base al carico. Se il traffico raddoppia non c’è un server da ingrandire a mano né uno sharding da riprogettare: è il compito che di solito ruba più tempo e che qui, sulla carta, sparisce.
La seconda è l’assenza di manutenzione a carico dell’utente. Non ci sono server da aggiornare, quindi non ci sono finestre di patching o di upgrade da pianificare, e non c’è il fermo tecnico che di solito le accompagna.
Compatibile con PostgreSQL, ma con dei limiti
Qui serve onestà, perché “compatibile” non vuol dire “identico”. Aurora DSQL parla il protocollo di PostgreSQL e ne supporta un’ampia parte delle funzionalità, ma non tutte: AWS mantiene una pagina di documentazione dedicata a cosa è supportato e cosa no. Prima di dare per scontato che un’applicazione PostgreSQL esistente giri senza modifiche, conviene controllare quell’elenco.
Ci sono poi vincoli sull’uso multi-regione. Al momento del lancio i cluster multi-regione si potevano creare solo tra regioni dello stesso raggruppamento geografico, e non erano supportate combinazioni tra continenti diversi. È un limite da mettere in conto se l’obiettivo è servire utenti sparsi su più continenti con un unico cluster.
Per quali casi ha senso
Aurora DSQL è ottimizzato per i carichi transazionali: tante operazioni piccole e frequenti - inserire un ordine, aggiornare un saldo, registrare un pagamento - dove contano affidabilità e coerenza. AWS lo indica come adatto ad architetture a microservizi, serverless ed event-driven, e cita ambiti come banche, e-commerce, viaggi, retail, piattaforme SaaS multi-tenant, pagamenti e gaming.
Vale anche il ragionamento opposto, per non usarlo dove non serve. Non è pensato come strumento di analisi su grandi moli di dati storici (i cosiddetti carichi analitici o OLAP), che seguono logiche diverse. E se un’applicazione ha bisogno di una funzione specifica di PostgreSQL non ancora supportata, o se un semplice database gestito su una sola regione copre già il fabbisogno, la complessità di un database distribuito può essere di troppo. La scelta giusta dipende dai requisiti concreti di disponibilità e di distribuzione geografica, non dalla novità in sé.
Il prezzo, in breve
Il modello di costo è a consumo. Si paga il lavoro svolto tramite delle unità chiamate DPU (Distributed Processing Units), che misurano letture e scritture, più lo spazio di archiviazione a GB-mese. AWS include una fascia gratuita mensile: le prime 100.000 DPU e 1 GB-mese di archiviazione ogni mese non si pagano. Per i conti veri conviene comunque partire dalla pagina prezzi ufficiale, perché il totale dipende molto da come si usa il database, proprio come succede quando si confrontano le offerte di più fornitori cloud.
