AWS ended support for Amazon Quantum Ledger Database on July 31, 2025. There was no keynote, no blog post, no public announcement — existing customers found out from a routine email and an updated documentation page. For teams that had built compliance workflows on QLDB, the notice marked the start of a migration window that closed faster than most expected. This post is for the buyers now evaluating replacements — and for anyone who wants their current migration to be the last one they have to do.
Why the AWS recommendation isn't quite an answer
AWS officially recommends migrating QLDB workloads to Amazon Aurora PostgreSQL, which offers ledger-like capabilities through extensions (see aws.amazon.com/qldb/faqs). Aurora provides detailed audit logging and permanent log retention. It does not provide cryptographic verifiability. That matters — the cryptographic hash chain was the reason many teams picked QLDB in the first place.
The practical consequence is that Aurora-based audit logs can be modified by a privileged administrator. The history exists; the tamper-evidence does not. Microsoft's own migration guide for QLDB customers (techcommunity.microsoft.com, moving from QLDB to Azure SQL Ledger) notes the same gap and positions Azure SQL Ledger's database-level ledger as a partial answer — but with the same single-vendor shape that QLDB's shutdown exposed.
The replacement criteria
The lesson from QLDB isn't that cloud ledgers are bad. It's that vendor-managed immutability has a business-decision failure mode. Any replacement should be evaluated against three criteria before you rebuild your integrity pipeline a second time:
- Can you verify without the vendor? QLDB's proofs required AWS API access. If the vendor's service endpoint goes away, the proofs go away with it. Certyo's anchors are verifiable against Polygon directly, with or without Certyo's cooperation.
- Is the trust anchor cloud-neutral? A ledger whose root-of-trust is a single cloud operator inherits that operator's business roadmap. Public blockchains and content-addressed storage don't share that failure mode.
- Are the proof artifacts portable? If your auditor or counterparty can't independently verify a proof package without access to your vendor account, the proof is a promise, not evidence.
The four realistic replacements
The practical replacement set is small. Each has a profile:
Aurora PostgreSQL gives you audit logs, not cryptographic proof. Azure SQL Ledger gives you database-level integrity but inherits the single-vendor risk. Azure Confidential Ledger adds TEE isolation but still runs in one cloud. Certyo anchors to Polygon and publishes proofs that work without us. None of the four is perfect; three of them are versions of the QLDB bet.
Why "cloud-native" was the original mistake
The phrase "cloud-native ledger" sounded sophisticated in 2019. In retrospect, it named the bug: a ledger that depends on the cloud is only as permanent as the cloud vendor's roadmap. Ledgers are supposed to survive their operators. A ledger that dies when its vendor sunsets the product isn't really a ledger — it's a database with retention guarantees.
The honest move is to treat this migration as the one that makes the next migration unnecessary. Pick a replacement whose proof artifacts survive the replacement itself. That narrows the field quickly.
Who this lesson hits hardest
Three groups need to make the next call deliberately:
- Former QLDB customers mid-migration — You've already lost cryptographic verifiability if you migrated to Aurora. If compliance scope still requires it, you're running on borrowed time with an interim solution.
- Teams evaluating ACL or Azure SQL Ledger — Both are live and both work. Both inherit single-vendor risk. If that's an acceptable trade for your organization, fine — but make it a conscious decision, not a default.
- Procurement and finance — Budget-wise, a second migration three to five years from now is the failure mode to prevent. The per-year delta between a vendor-locked replacement and a vendor-neutral one is small; the delta in migration-risk exposure is large.
What changes this time and sources
The thing that makes the post-QLDB market different is that the alternatives now exist. Public-chain anchoring has matured. Batch economics make per-record costs negligible. IPFS content-addressing is production-ready. None of these were obviously production-grade in 2019; they are now. The honest case for a vendor-neutral replacement is that the 2025 migration is avoidable going forward. Sources: InfoQ — infoq.com/news/2024/07/aws-kill-qldb, AWS FAQ — aws.amazon.com/qldb/faqs, Microsoft migration guide — techcommunity.microsoft.com/blog/azuresqlblog/moving-from-amazon-quantum-ledger-database-qldb-to-ledger-in-azure-sql/4246237, DoltHub alternatives — dolthub.com/blog/2024-08-12-qldb-deprecated-alternatives. See also our /en/compare/aws-qldb page for a direct Certyo comparison.
A ledger that dies when its vendor sunsets the product isn't a ledger. It's a database with retention guarantees. Pick the replacement that survives the next sunset.