Amazon QLDB (Quantum Ledger Database): Discontinued Service

IMPORTANT NOTICE: Amazon QLDB Discontinuation

As of July 2024, AWS announced the discontinuation of Amazon Quantum Ledger Database (QLDB). The service was fully shut down on July 31, 2025. New ledger creation is no longer possible and existing ledgers have been retired. AWS recommends that affected users migrate to alternatives such as Amazon Aurora PostgreSQL, which can provide ledger-like capabilities with application-level patterns.

This article is maintained for informational and archival purposes — to help developers and architects working on legacy QLDB code or studying historical AWS services. For any new project, choose an alternative.

Definition

Amazon Quantum Ledger Database (QLDB) was a fully managed, serverless ledger database for applications that required a centralized, transparent, immutable, and cryptographically verifiable transaction log. It was designed to act as a system of record, providing an authoritative and tamper-evident history of every change to application data.

How It Worked

QLDB's architecture was built around an immutable, append-only journal — the authoritative source of truth that recorded every data change sequentially.

The Journal — Data was stored in a journal of sequential blocks. Blocks were cryptographically chained using SHA-256 hashes. Once a transaction was committed, it could not be altered or deleted.
Data Model — QLDB used a document-oriented model storing data in Amazon Ion format (a superset of JSON). Updates and deletes appended new versions or deletion markers to the journal, preserving the full history.
Cryptographic Verification — QLDB could generate a digest, a secure hash representation of the journal at a point in time. Applications could later prove no modifications had occurred between two digests.
Querying — Data was queried using PartiQL, a SQL-compatible language that worked with structured, semi-structured, and nested data.

Key Features and Limits

Immutability and Verifiability — append-only journal with cryptographic chaining.
Serverless — no server provisioning or capacity management; auto-scaled with demand.
ACID Transactions — atomicity, consistency, isolation, and durability for ledger operations.
QLDB Streams — near-real-time streaming of journal data to Amazon Kinesis Data Streams for event-driven architectures.
Journal Exports — direct export of journal data to Amazon S3 for archival and analytics.
Service Quotas — capped active ledgers per account/region and active streams/exports per ledger.

Common Use Cases (Historical)

QLDB was designed for systems of record where a complete, verifiable transaction history was critical.

Finance and Banking — full history of credit/debit transactions for audits and reconciliation.
Supply Chain and Logistics — verifiable audit trail of an item's journey from manufacture to delivery.
HR and Payroll — immutable record of employee details, salary changes, and benefits for compliance.
Government and Compliance — vehicle registration, licensing, regulatory data with unimpeachable change history.
Insurance — full claim lifecycle from filing through adjustments and payments with cryptographic verification.

Pricing Model (Historical)

QLDB used pay-per-use pricing with no upfront fees:

Write I/Os — per million write requests.
Read I/Os — per million read requests.
Journal Storage — per GB-month for the immutable journal.
Indexed Storage — per GB-month for tables and indexes.
Data Transfer — standard AWS data transfer charges for egress.

Pros and Cons

Pros (Why it was created)

High Data Integrity — cryptographically verifiable, immutable journal made it ideal for systems of record.
Developer-Friendly — familiar SQL-like PartiQL and a document data model lowered the barrier vs. blockchain frameworks.
Serverless and Fully Managed — no infrastructure overhead.
Performance — centralized design avoided distributed consensus, executing transactions 2–3× faster than typical blockchain frameworks.

Cons (Limitations and outcome)

Discontinued Service — the most significant con; the service was retired on July 31, 2025 and is unsuitable for any new use.
Centralized Trust Model — unlike true blockchains, verification depended on trusting AWS as the central authority.
Niche Use Case — not a general-purpose database; lacked flexibility for non-ledger workloads.
Limited Features — no cross-region replication and no customer-managed encryption keys (CMKs).

Comparison with Alternatives

QLDB vs. Amazon DynamoDB — DynamoDB is a NoSQL key-value/document database built for high-performance transactional workloads. It supports ACID transactions and DynamoDB Streams but does not provide an immutable, cryptographically verifiable history out of the box. Use DynamoDB for speed and scale; QLDB was for data lineage and auditability.
QLDB vs. Amazon Managed Blockchain — QLDB was a centralized ledger owned by one AWS account. Managed Blockchain enables decentralized applications across multiple parties without a central authority, using frameworks like Hyperledger Fabric. QLDB was for verifiable history within one organization; Managed Blockchain is for decentralized consensus across organizations.
QLDB vs. Amazon Aurora PostgreSQL — AWS's recommended migration target. Aurora PostgreSQL with application-level append-only patterns and cryptographic hash chaining can replicate most ledger semantics, with the trade-off that immutability and verification become application responsibilities rather than database features.

Exam Relevance

Amazon QLDB historically appeared on the AWS Certified Database – Specialty and AWS Certified Solutions Architect – Associate (SAA-C03) exams. Common topics:

Recognizing the canonical QLDB use case: a centralized, immutable ledger as a system of record.
Differentiating QLDB from Amazon Managed Blockchain (centralized vs. decentralized trust model).
Choosing QLDB over DynamoDB or RDS when immutability and cryptographic verifiability were the deciding factors.

The service is retired, but the underlying concepts (immutable logs, centralized vs. decentralized trust) remain relevant for solution design.

Frequently Asked Questions

Q: Was Amazon QLDB a blockchain?

A: No. QLDB was a centralized ledger database, not a decentralized blockchain. It borrowed concepts from blockchain technology — append-only logs and cryptographic hashing — but was owned and operated by a single trusted authority within one AWS account, with no distributed consensus mechanism.

Q: Could you delete data from Amazon QLDB?

A: You could not delete or alter data in the underlying journal — it was strictly append-only and immutable. A DELETE in PartiQL removed a document from a table's current state, but the deletion itself was recorded as a new transaction in the journal, preserving the full auditable history including the deletion event.

Q: How did you verify data integrity in QLDB?

A: Verification was a two-step process. You requested a digest (a hash) of your ledger from QLDB for a specific point in time and stored it securely. Later, to verify a transaction, you provided QLDB with the transaction details and the stored digest, and QLDB recomputed the hashes across the relevant journal blocks to prove the transaction existed and had not been tampered with since the digest was generated.

This article reflects Amazon QLDB's features and pricing prior to its July 31, 2025 shutdown. AWS services evolve rapidly — always verify against the official AWS documentation before making decisions.