AWS Database
QLDB
Managed ledger database with an immutable, cryptographically verifiable transaction log
Amazon QLDB (Quantum Ledger Database) is a fully managed ledger database that provides a transparent, immutable, and cryptographically verifiable transaction log. Every change to the data is appended to a journal that cannot be altered or deleted - unlike a regular database where rows can be overwritten. QLDB is designed for applications that need a complete, verifiable audit trail: financial ledgers, supply chain provenance, healthcare records, and regulatory compliance use cases.
How QLDB Works: The Journal and Document Store
QLDB has two layers: the journal (the append-only, immutable log of every transaction) and the current state (a queryable view of the latest version of each document). The journal is the source of truth; the current state is derived from the journal.
| Component | Description | Key Property |
|---|---|---|
| Journal | Append-only, immutable log of all transactions in sequence order | Cannot be altered or deleted; cryptographically chained |
| Current state | Queryable view of latest document versions | Derived from journal; supports SQL-like PartiQL queries |
| Document revision | Each update creates a new revision in the journal | Full history of every field change preserved |
| Digest | Cryptographic hash of the entire journal at a point in time | Used to verify the ledger has not been tampered with |
| Proof | Merkle audit proof for a specific document revision | Proves a revision is in the journal without scanning everything |
QLDB uses a hash-chained journal, similar to a blockchain but without distributed consensus (AWS manages the ledger centrally). You can verify that any document revision is authentic and that no revisions have been retroactively deleted or modified.
PartiQL: Querying QLDB Data
QLDB uses PartiQL, an SQL-compatible query language developed by AWS that supports nested and semi-structured data. It feels like SQL with JSON support.
-- Insert a document
INSERT INTO Accounts VALUE {
'accountId': 'acc-001',
'owner': 'Alice',
'balance': 5000.00,
'status': 'active'
}
-- Query current state
SELECT accountId, owner, balance
FROM Accounts
WHERE accountId = 'acc-001'
-- Update (creates a new journal entry; old revision preserved)
UPDATE Accounts
SET balance = balance - 500.00
WHERE accountId = 'acc-001'
-- Query document history (all revisions)
SELECT * FROM history(Accounts)
WHERE metadata.id = '<document-id>'
ORDER BY metadata.version
-- Verify a document revision using a digest
-- (done via the QLDB SDK, not PartiQL)
// ledger.getDigest() -> get current digest
// ledger.getRevision(tableId, documentId, blockAddress, digestTipAddress)
// -> returns proof object for cryptographic verificationQLDB vs Audit Tables vs Blockchain: When to Use Each
QLDB is often confused with audit logging patterns in regular databases or with blockchain technologies. Understanding when to use each is a common architecture discussion.
| Approach | Tamper Evidence | Distributed Trust | Complexity | Use Case |
|---|---|---|---|---|
| QLDB | Yes - cryptographic hash chain | No - AWS is trusted central party | Low | Internal audit trail; regulatory compliance; financial ledger |
| Audit table (triggers/CDC) | No - DBA can delete audit rows | No | Low | Simple change history; no tamper-evidence needed |
| Immutable S3 (Object Lock) | Yes - S3 Object Lock prevents deletion | No - AWS trusted | Medium | Compliance archival; log storage |
| Blockchain (Managed Blockchain / Hyperledger) | Yes | Yes - multiple parties verify | High | Multi-party systems where no single party is trusted |
QLDB is not a blockchain. It is a centralized ledger managed by AWS. If your use case requires multiple untrusted parties to verify transactions without a central authority, you need a true blockchain solution. QLDB is appropriate when you trust AWS as the operator and need a verifiable audit trail for your own application data.
QLDB Streams: Real-Time Journal Processing
QLDB Streams continuously delivers journal data to Amazon Kinesis Data Streams in near real-time. This enables event-driven architectures where downstream systems react to every change in the ledger.
| Feature | Detail |
|---|---|
| Destination | Kinesis Data Streams only |
| Data format | Ion format (QLDB's native format) or JSON |
| Latency | Near real-time (seconds) |
| Use case | Event sourcing, search indexing, audit log forwarding to SIEM, downstream triggers |
| Ordering | Ordered by journal sequence number within a shard |
# Create a QLDB stream to Kinesis
aws qldb create-journal-kinesis-stream \
--ledger-name my-ledger \
--stream-name my-ledger-stream \
--role-arn arn:aws:iam::123456789012:role/QLDBKinesisRole \
--kinesis-configuration "StreamArn=arn:aws:kinesis:us-east-1:123456789012:stream/qldb-stream,AggregationEnabled=true" \
--inclusive-start-time 2024-01-01T00:00:00ZPricing Model and Limitations
| Component | Pricing Basis |
|---|---|
| Write I/O | Per million write request units |
| Read I/O | Per million read request units |
| Journal storage | Per GB-month (journal grows indefinitely; cannot delete entries) |
| Indexed storage | Per GB-month for current-state queryable data |
| Data transfer | Standard AWS data transfer rates |
The QLDB journal grows forever and cannot be truncated or deleted. Journal storage costs accumulate over time. For workloads with high write volumes, journal storage can become the dominant cost. Evaluate the long-term storage trajectory before committing to QLDB for high-frequency transaction systems.
QLDB does not support multi-region replication or cross-region failover. It operates in a single region. If you need geographic redundancy, you must stream journal entries to another region via Kinesis and replay them into a secondary ledger.
Interview Focus Points
- 1What is QLDB and what problem does it solve? How is it different from a regular database with audit tables?
- 2Explain the QLDB journal. Why is it called immutable and cryptographically verifiable?
- 3When would you choose QLDB over a blockchain like Amazon Managed Blockchain?
- 4What is a document revision in QLDB and how do you query document history?
- 5What are QLDB Streams and what are common use cases for them?
- 6What are the limitations of QLDB? What types of workloads is it not suitable for?
- 7How does QLDB handle multi-region availability and disaster recovery?
- 8What is a cryptographic digest in QLDB and how is it used to verify data integrity?
- 9Describe a financial services use case where QLDB would be the appropriate database choice.