Skip to main content
In this lesson we explain AWS Quantum Ledger Database (QLDB): what problems it solves, how it stores and verifies data, typical use cases, and key technical details. Why use a ledger-style database like QLDB?
  • Immutable, auditable history: QLDB preserves a tamper-evident audit trail of every change.
  • Verifiability: Cryptographic hashing and digest proofs let you verify the integrity of the ledger.
  • Managed service: QLDB is fully managed and serverless, minimizing operational overhead.
  • SQL-like querying: PartiQL provides familiar query semantics over document data stored in Amazon Ion.
  • ACID transactions: Ensures correctness for transactional workloads requiring strict consistency.
Problems with traditional databases for tamper-evident ledgers
  • Mutability: Updates and deletes overwrite records and erase history.
  • Limited transparency: Historical changes are not always accessible or verifiable.
  • Centralization risk: Single-owner systems can introduce trust and availability concerns.
  • Single points of failure: An outage can make the whole system unavailable.
  • No built-in consensus or verifiability: Traditional databases lack cryptographic proofs for audit.
  • Weak privacy controls for ledger-style selective disclosure.
QLDB addresses these concerns by providing a managed, immutable journal with cryptographic verifiability while still supporting SQL-like queries and serverless operation.
A slide diagram comparing a Traditional Database (showing tables, transaction logs, and replay) with AWS QLDB, highlighting a Journal and an Append-Only Data Structure. The right side features a colorful journal icon and connected blocks representing the append-only ledger.

​
How QLDB works

At the core of QLDB is an append-only journal that records every successful write (insert, update, delete) as an immutable journal block. The journal stores:
  • the entry documents (in Amazon Ion),
  • the PartiQL statements executed,
  • transaction metadata (timestamps, block IDs),
  • cryptographic hashes linking blocks together.
QLDB exposes two logical views of the same data:
  • Current table: the latest state of each document for efficient read access.
  • History table: a complete, immutable record of all prior versions for auditing.
Example lifecycle (car ownership):
  • First sale: a journal block is appended with the sale record; Current and History reflect the initial state.
  • Subsequent sale: a new block is appended, Current is updated to the new owner, and History gets an additional version.
  • Each block is sequenced and chained; the entire sequence is cryptographically verifiable.
A slide titled "AWS QLDB in Action" showing a journaled event flow of car records (Tesla Model S) with sequential insert events and event processing. Below are tables showing the current state (ID 1, owner Smith) and a history of versions/owners (John, Thomas, Smith).
You can also stream journal events to downstream systems for integration or analytics.

​
Cryptographic verification: hash-chaining and proofs

QLDB chains journal blocks using SHA-256 hashes. Each block contains a hash that links it to the previous block, producing an immutable sequence. QLDB exposes:
  • a digest for a ledger at a point in time,
  • Merkle-style (Merkle tree) audit proofs to prove existence or non-existence of a document at a given revision,
  • APIs to verify that a returned result corresponds to the latest digest.
This design provides strong tamper-evidence while letting a trusted owner operate the ledger.
A diagram showing AWS QLDB's cryptographically verifiable ledger, illustrating SHA-256 hash chaining across journal blocks. It also shows a block structure with entries (Amazon Ion documents, PartiQL, metadata) and a block hash.
Important: QLDB provides cryptographic proof and an immutable journal, but it is operated by a single trusted authority (the ledger owner). QLDB is not a decentralized blockchain platform; it is a centralized, verifiable ledger optimized for auditability and provenance.

​
Key technical details (at a glance)

​
PartiQL sample queries

Insert a document:
Query the current state:
Get document history (example using QLDB revision functions):

​
Typical use cases

  • Financial transaction ledgers (auditable purchase and settlement records)
  • Supply chain provenance (track item lifecycle and origin)
  • Claims history and regulatory records (verifiable audit trails and evidence)
  • Any system requiring full data lineage and cryptographic verification
A slide titled "AWS QLDB - Features" showing three colored panels labeled "SQL-like and Document Flexible," "Serverless and Highly Available," and "Enterprise Grade," each with a simple icon (SQL document, cloud, building).
A slide titled "QLDB – Use Cases" showing three colored panels labeled "Financial Transaction," "Supply Chain Systems," and "Claim History," each with a simple white icon. The slide includes a small copyright notice for KodeKloud.
Warning: QLDB is operated by a single trusted entity and is not a decentralized ledger with consensus across untrusted parties. Choose a different blockchain platform if you need distributed trust without a central authority.

​
Summary

  • Amazon QLDB is a fully managed ledger database that delivers a transparent, immutable, and cryptographically verifiable transaction journal that an owner controls.
  • The journal is append-only, sequenced, and hash-chained; each transaction is recorded as a block with documents, PartiQL statements, and metadata.
  • QLDB presents data via Current and History logical tables: fast access to the latest state and a complete immutable history for audits and provenance.
  • It combines enterprise-grade ACID transactions, PartiQL query compatibility, Amazon Ion document flexibility, and cryptographic proofs for verifiability.
A presentation slide titled "Summary QLDB" with a turquoise left panel. The right side shows three numbered points describing QLDB as a fully managed, immutable, cryptographically verifiable transaction journal.
Use QLDB when you need a managed, verifiable ledger for audit, provenance, and data lineage while maintaining SQL-like query capabilities and serverless operation.

Watch Video