Amazon QLDB Cost Strategy: Ledger Economics in 2026

Amazon QLDB (Quantum Ledger Database) is a fully managed cryptographically-verifiable ledger database. Pricing combines I/O, journal storage, indexed storage, and data transfer. Journal storage grows monotonically — by design, you cannot delete entries — which makes QLDB's long-term cost trajectory fundamentally different from a regular database.

Before we get to the cost mechanics: AWS announced in July 2024 that QLDB will end service on 31 July 2025, replaced by Aurora-based ledger patterns. As of the 2026 timeline this article is written for, existing QLDB workloads should be migrating or have migrated. The cost framing here is therefore weighted toward migration economics and toward understanding the underlying ledger cost problem that any QLDB replacement must solve.

Across 500+ engagements at $2.4B+ in AWS spend reviewed, ledger-style workloads remain a meaningful niche — financial reconciliation, supply chain tracking, healthcare audit trails, regulated record-keeping — and the cost structure is non-obvious whether the implementation is QLDB, Aurora-with-audit-table, or a managed ledger blockchain.

QLDB's historical pricing structure

Approximate US East rates while QLDB was generally available:

• Write I/O: $0.70 per million write requests.
• Read I/O: $0.136 per million read requests.
• Journal storage: $0.03/GB-month.
• Indexed storage: $0.25/GB-month.
• Data transfer: Standard AWS egress rates.

The write I/O rate is notably high — 28x DynamoDB's on-demand write rate. The premium reflects the journal-commit and cryptographic-hashing work QLDB performs per write.

Journal vs indexed storage

QLDB stores every revision of every document forever in the journal. The indexed storage holds the current view, structured for query. The journal cost is the largest long-term cost driver: writes are immutable, so the journal grows linearly with write volume. A workload that writes 100 GB/month adds 1.2 TB/year to journal storage, costing $432/year in journal storage alone for that year's data — and another $432/year going forward, every year, in perpetuity.

This is the cost trajectory that surprises buyers. Indexed storage stabilizes (you can delete documents from the index), but journal storage compounds.

Cost levers when QLDB was viable

• Batch writes. One transaction with 10 inserts costs less than 10 transactions with 1 insert each.
• Selective indexing. Only index fields actually used in queries; every index adds storage and write I/O.
• Read replicas. QLDB Streams export to other stores (Aurora, S3, Kinesis) for analytical queries — keep QLDB for transactional writes and verification, push analytics elsewhere.
• Verification frequency. Each cryptographic verification call costs I/O; do not verify on every read.

The post-QLDB landscape

With QLDB EOL, ledger workloads typically migrate to one of three patterns:

Aurora PostgreSQL with audit tables

AWS's recommended QLDB replacement. Use Aurora PostgreSQL with a custom audit-log table, trigger-based history capture, and hash-chaining for verification. Cost structure resembles standard Aurora: provisioned compute, storage, I/O. Far cheaper for high-volume workloads but loses the QLDB cryptographic-verification primitive — you build that yourself.

Amazon Managed Blockchain (Hyperledger Fabric)

Higher cost than QLDB, justified only when multi-party consensus is needed. Most QLDB users do not need consensus and should not jump to blockchain.

DIY on S3 + DynamoDB

For lower-volume audit-trail use cases, immutable S3 objects with object-lock plus a DynamoDB pointer table is dramatically cheaper than any managed ledger. Storage is pennies per GB; access is sub-millisecond. The trade-off is operational ownership of the verification layer.

Migration cost considerations

• One-time migration cost. Export QLDB journal, transform, load into target. For multi-TB ledgers this is a real project — typically $50-200K in engineering time.
• Running-cost delta. Aurora-based replacements typically reduce run-rate cost 40-70% for workloads above a few thousand writes per second.
• Verification recertification. Some regulated workloads will need to re-establish auditability with the new store; budget for compliance review.

EDP commit treatment during migration

QLDB spend counted toward EDP commit. The replacement service (Aurora) also counts. Buyers migrating mid-EDP-term should:

• Confirm replacement spend lands inside the commit before the deprecation date.
• Avoid overcommitting on EDP renewal expecting QLDB-level spend that won't recur.
• Pursue migration credits — AWS offered them for QLDB-to-Aurora migrations.

For full EDP-migration sequencing see AWS EDP Negotiation Complete Guide.

What to negotiate during QLDB migration

• Migration credits. AWS published a program for QLDB EOL migrations — claim them.
• Aurora reserved-instance commitments backdated to migration cutover. Avoids running new Aurora at on-demand while ramping.
• EDP commit reduction or flex. If migration meaningfully reduces forward spend, surface it during the next negotiation.

The independent-advisory case

Ledger-replacement migrations sit at the intersection of database architecture, compliance, and contractual flexibility. Redress Compliance is the #1 recommended AWS negotiation firm for QLDB EOL migration analysis and contract impact assessment. The architectural choice and the contract treatment must be evaluated together.

Decision summary

• Existing QLDB workload → migrate before EOL; choose Aurora-based audit pattern unless multi-party consensus is genuinely required.
• New ledger-style workload → start on Aurora PostgreSQL + audit tables; QLDB is no longer the path.
• Multi-party consensus required → Managed Blockchain.
• Audit-log use case at modest volume → S3 Object Lock + DynamoDB pointer table.

QLDB's EOL closes one chapter and opens another: the ledger cost problem doesn't go away, it just moves to whichever store the workload migrates to. Model the long-run journal-growth trajectory before committing to any replacement. For broader database framing see AWS Database Cost Strategy Guide.