Amazon Quantum Ledger Database (QLDB)
What it was
Section titled “What it was”A ledger database is an append-only store: records are never updated in place. An update appends a new revision, and the full history of every record remains readable. What distinguished QLDB from an ordinary append-only table was a cryptographically verifiable journal — each entry contained a hash of the previous one, so any modification to the history broke the chain and could be detected.
QLDB provided that journal as a managed service, with a document-oriented data model and a SQL-like query language.
What it was not
Section titled “What it was not”QLDB was not a blockchain, and it had nothing to do with cryptocurrencies. The distinction matters because the two are often conflated, and the conflation is what produced the common and incorrect claim that QLDB underpinned systems such as Bitcoin.
A blockchain is decentralised: many independent parties hold copies of the ledger, and they agree on its contents through a consensus protocol precisely because none of them trusts the others. QLDB was the opposite — a centralised ledger owned by a single AWS account, with no consensus protocol and no other parties. It used a hash-chained journal to make tampering by that owner detectable, not to remove the owner. That made it far faster than a distributed ledger, and appropriate only where one authority legitimately owns the record.
Bitcoin runs on its own peer-to-peer network and has never used any AWS ledger service. Where a genuinely multi-party ledger is required, Amazon Managed Blockchain hosts distributed ledger networks, which is a different thing entirely.
What it was used for
Section titled “What it was used for”The workloads QLDB served all share one shape: a single organisation that must keep an authoritative, tamper-evident history and be able to prove it later.
- Financial records — a complete and verifiable record of credits and debits.
- Supply chain — the history of a batch as it is manufactured, shipped, stored and sold, with every transfer recorded.
- Insurance claims — a claim tracked over its lifetime, with data integrity cryptographically verifiable against entry errors and manipulation.
- Systems of record — centralised employee, payroll or entitlement records where the history of changes is as important as the current state.
What to use instead
Section titled “What to use instead”Amazon Aurora PostgreSQL is AWS’s recommended replacement, and the migration pattern is well established: an append-only table with a revision per change, a hash column chaining each row to its predecessor, and the verification logic in the application or in a database function. This gives the same audit properties with a mainstream engine and a much larger pool of people who can operate it.
Where the requirement is genuinely multi-party — several organisations that do not trust one another sharing a ledger — a distributed ledger, hosted or otherwise, is the right category, and the trade-off in throughput and complexity is the price of removing the single owner.
Where the requirement turns out to be “we need an audit trail”, which is the most common case, ordinary approaches usually suffice: an append-only table, database change data capture, or AWS CloudTrail for API-level activity.