AWS ha terminato il supporto per Amazon Quantum Ledger Database il 31 luglio 2025. Nessun keynote, nessun blog post, nessun annuncio pubblico — i clienti esistenti l'hanno saputo da un'email di routine e una pagina di documentazione aggiornata. Per i team che avevano costruito flussi di conformità su QLDB, l'avviso ha segnato l'inizio di una finestra di migrazione che si è chiusa più velocemente di quanto la maggior parte si aspettasse. Questo articolo è per gli acquirenti che ora valutano sostituti — e per chiunque voglia che la migrazione attuale sia l'ultima che debbano fare.
Perché la raccomandazione AWS non è del tutto una risposta
AWS raccomanda ufficialmente di migrare i workload QLDB su Amazon Aurora PostgreSQL, che offre capacità tipo ledger tramite estensioni (vedi aws.amazon.com/qldb/faqs). Aurora fornisce logging di audit dettagliato e ritenzione permanente dei log. Non fornisce verificabilità crittografica. Questo conta — la catena di hash crittografica era il motivo per cui molti team hanno scelto QLDB in primo luogo.
La conseguenza pratica è che i log di audit basati su Aurora possono essere modificati da un amministratore privilegiato. La storia esiste; la prova di manomissione no. La stessa guida di migrazione di Microsoft per i clienti QLDB (techcommunity.microsoft.com, moving from QLDB to Azure SQL Ledger) nota la stessa lacuna e posiziona il Ledger a livello database di Azure SQL Ledger come risposta parziale — ma con la stessa forma di singolo vendor che la chiusura di QLDB ha esposto.
I criteri di sostituzione
La lezione di QLDB non è che i ledger cloud siano cattivi. È che l'immutabilità gestita dal vendor ha una modalità di fallimento da decisione di business. Qualsiasi sostituto dovrebbe essere valutato contro tre criteri prima di ricostruire la tua pipeline di integrità una seconda volta:
- Puoi verificare senza il vendor? Le prove QLDB richiedevano accesso API AWS. Se l'endpoint del servizio del vendor sparisce, le prove spariscono con esso. Le ancore di Certyo sono verificabili contro Polygon direttamente, con o senza cooperazione di Certyo.
- L'ancora di fiducia è neutrale al cloud? Un ledger la cui radice di fiducia è un singolo operatore cloud eredita la roadmap di business di quell'operatore. Le blockchain pubbliche e lo storage indirizzato per contenuto non condividono quella modalità di fallimento.
- Gli artefatti di prova sono portabili? Se il tuo auditor o controparte non può verificare indipendentemente un pacchetto di prove senza accesso al tuo account vendor, la prova è una promessa, non evidenza.
I quattro sostituti realistici
L'insieme pratico di sostituti è piccolo. Ciascuno ha un profilo:
Aurora PostgreSQL ti dà log di audit, non prova crittografica. Azure SQL Ledger ti dà integrità a livello database ma eredita il rischio di vendor singolo. Azure Confidential Ledger aggiunge isolamento TEE ma corre ancora in un singolo cloud. Certyo ancora a Polygon e pubblica prove che funzionano senza di noi. Nessuno dei quattro è perfetto; tre di essi sono versioni della scommessa QLDB.
Perché "nativo cloud" era l'errore originale
La frase "ledger nativo cloud" suonava sofisticata nel 2019. Col senno di poi, nominava il bug: un ledger che dipende dal cloud è permanente solo quanto la roadmap del vendor cloud. I ledger dovrebbero sopravvivere ai loro operatori. Un ledger che muore quando il suo vendor chiude il prodotto non è davvero un ledger — è un database con garanzie di ritenzione.
La mossa onesta è trattare questa migrazione come quella che rende la prossima non necessaria. Scegli un sostituto i cui artefatti di prova sopravvivano alla sostituzione stessa. Questo restringe il campo rapidamente.
A chi colpisce di più questa lezione
Tre gruppi devono prendere la prossima decisione deliberatamente:
- Ex-clienti QLDB a metà migrazione — Hai già perso la verificabilità crittografica se hai migrato ad Aurora. Se l'ambito di conformità lo richiede ancora, stai correndo con tempo preso in prestito su una soluzione intermedia.
- Team che valutano ACL o Azure SQL Ledger — Entrambi sono vivi ed entrambi funzionano. Entrambi ereditano il rischio di vendor singolo. Se quello è un trade accettabile per la tua organizzazione, bene — ma che sia una decisione conscia, non un default.
- Acquisti e finance — In termini di budget, una seconda migrazione tra tre a cinque anni è la modalità di fallimento da prevenire. Il delta per anno tra un sostituto con vendor lock-in e uno neutrale al cloud è piccolo; il delta in esposizione al rischio di migrazione è grande.
Cosa cambia questa volta e fonti
Ciò che rende diverso il mercato post-QLDB è che le alternative ora esistono. L'ancoraggio su catena pubblica è maturato. L'economia dei batch rende i costi per-record trascurabili. L'indirizzamento per contenuto IPFS è pronto per la produzione. Nessuna di queste era ovviamente grado-produzione nel 2019; lo sono ora. Il caso onesto per un sostituto neutrale al cloud è che la migrazione del 2025 è evitabile d'ora in poi. Fonti: InfoQ — infoq.com/news/2024/07/aws-kill-qldb, AWS FAQ — aws.amazon.com/qldb/faqs, guida migrazione Microsoft — techcommunity.microsoft.com/blog/azuresqlblog/moving-from-amazon-quantum-ledger-database-qldb-to-ledger-in-azure-sql/4246237, alternative DoltHub — dolthub.com/blog/2024-08-12-qldb-deprecated-alternatives. Vedi anche la nostra pagina /it/compare/aws-qldb per un confronto Certyo diretto.
Un ledger che muore quando il suo vendor chiude il prodotto non è un ledger. È un database con garanzie di ritenzione. Scegli il sostituto che sopravvive alla prossima chiusura.