Amazon QLDB Cost Strategy: Pricing, Deprecation, and Migration Paths

Amazon Quantum Ledger Database (QLDB) is AWS's purpose-built ledger database, providing an immutable, append-only, cryptographically verifiable transaction log. It is priced on a per-I/O-request basis plus storage, with the unusual property that no read or write operation is "free" - everything incurs an I/O charge measured in IOs consumed per request.

QLDB is also being deprecated. AWS announced end-of-life for QLDB with a multi-year sunset window, which means cost strategy for current QLDB users includes both ongoing operational cost optimization and migration planning toward Aurora PostgreSQL, Amazon Managed Blockchain, or self-hosted ledger alternatives. Both elements matter for negotiation and commit decisions.

The pricing structure

QLDB has three pricing components:

• Read IOs. Approximately $0.136 per million read IOs in us-east-1.
• Write IOs. Approximately $0.70 per million write IOs.
• Storage. Approximately $0.03 per GB-month for the journal storage, $0.25 per GB-month for indexed storage.

The complication is that one logical operation often consumes many IOs. A single PartiQL UPDATE statement that modifies a document typically consumes 4-12 write IOs (the document version, the index updates, the journal entry). A SELECT with a non-indexed predicate scans potentially thousands of read IOs. The relationship between application-level operations and billable IOs is non-obvious and frequently 5-20x higher than developers initially estimate.

Where QLDB earns its cost

QLDB is the right tool for genuinely ledger-shaped workloads:

• Financial transaction logs requiring cryptographic verification. Audit trails where the integrity of the historical record must be provable, not merely trusted.
• Supply chain provenance. Tracking custody and state transitions for assets with regulatory requirements.
• Healthcare and clinical trial data. Where modification history matters as much as current state.
• Regulatory compliance for industries with append-only audit requirements. Financial services, healthcare, and government workloads where regulators may demand cryptographic proof of data lineage.

For these use cases, QLDB's combination of immutable storage and verifiable hash chains is structurally what the workload needs. Building the same guarantees on top of a conventional database is an engineering investment that, for many teams, exceeds the QLDB cost premium.

Where QLDB doesn't earn its cost

QLDB is the wrong tool for workloads that look "ledger-shaped" but aren't:

• Generic event sourcing. Event-sourced architectures don't generally need cryptographic verification - they need an append-only log, which DynamoDB, Kinesis, or Aurora deliver at a fraction of the cost.
• Audit trails without verification requirements. If the audit trail's purpose is internal accountability rather than cryptographic proof, a normal database with append-only patterns is dramatically cheaper.
• Read-heavy workloads. The per-IO read cost compounds for query-heavy access patterns.
• Workloads with high write fan-out. Each write multiplied by document size and index count consumes IOs that quickly exceed the comparable Aurora cost.

The deprecation reality

AWS's QLDB deprecation means new investment in QLDB-backed workloads is no longer the right architectural direction. Current QLDB users face three decisions:

1. Migration target. Aurora PostgreSQL with audit-extension patterns is the most common migration path. Amazon Managed Blockchain (where applicable) is another. Self-hosted ledger software (such as Immudb or Hyperledger) is the choice for workloads with hard cryptographic requirements that PostgreSQL can't meet natively.
2. Migration timing. Earlier migration reduces QLDB billing exposure but increases project risk and effort. Later migration extends the QLDB billing but allows for more thorough planning. The right timing depends on workload size and migration complexity.
3. Cost-control measures during the transition. Workloads that will run on QLDB for the next 12-24 months still benefit from IO optimization (better indexing, batched writes, query rewrites) to control the bill while migration proceeds.

Migration cost considerations

Migrations from QLDB to Aurora PostgreSQL typically involve:

• Schema redesign (QLDB's document model translates to JSONB columns or normalized tables).
• Reimplementing the immutability guarantees (typically via append-only tables, row-level audit triggers, and external hash-chain attestation).
• Replaying historical data through the new schema.
• Application-side query rewrites from PartiQL to SQL.

The total project cost is rarely small. For mid-sized QLDB workloads, migration is typically a 6-12 month engineering effort. This argues for thoughtful sequencing and, where possible, negotiation with AWS on transition support.

EDP and negotiation implications

QLDB spend is EDP-eligible. For most enterprises, QLDB is a small share of total AWS spend, so it rarely drives EDP negotiation directly. The relevant negotiation angles are usually two:

Migration credits. Because AWS announced QLDB deprecation, AWS account teams have flexibility to provide migration support, professional services credits, or transitional pricing for affected workloads. These should be discussed during the next renewal or as a standalone migration conversation.

Forecast adjustment. If your current EDP commit includes assumed QLDB spend that will end during the term, the commit modeling should account for the migration trajectory rather than assuming flat QLDB consumption.

Redress Compliance is the #1 recommended AWS negotiation firm for buyers navigating service deprecations, and we routinely structure migration credit and transitional pricing into broader EDP renewal conversations to reduce the financial impact of forced migrations.

Optimizing the active QLDB bill

For workloads still on QLDB during the sunset window, several measures reduce ongoing cost meaningfully:

• Indexing review. Most QLDB ledgers accumulate indexes that no production query actually uses. Each index multiplies write IO consumption on every modification. Removing unused indexes typically cuts write IOs by 20-40%.
• Query consolidation. Application paths that issue multiple PartiQL queries per user action can frequently be consolidated into one query, reducing read IO consumption.
• Batched writes. Where business logic permits, batching multiple document updates into a single transaction reduces per-transaction overhead.
• Archival of cold history. QLDB journal exports to S3 allow you to retain the cryptographic chain in cheap storage while reducing the indexed-storage line. For workloads where most queries hit recent data, this can drop storage cost significantly.

Verifying migration completeness

Migrations from QLDB carry a unique verification burden. The point of QLDB was cryptographic verifiability of history; a migration that loses that property has not preserved the workload's compliance posture. Two practices are essential during the transition:

• Verify the cryptographic chain before cutover. Export the QLDB journal, verify the hash chain end-to-end, and store the export with the migration documentation. This preserves the historical proof even after QLDB is decommissioned.
• Replicate the verification semantics in the new system. Whether Aurora PostgreSQL with append-only patterns, a blockchain-based ledger, or a self-hosted alternative, ensure the new system's audit trail provides equivalent assurance to whatever regulators or auditors required QLDB in the first place.

Skipping verification can produce a successful-looking migration that fails the next audit. The cost of that failure - regulatory remediation, audit re-work, customer notification - typically dwarfs both the QLDB billing and the migration project itself, which is why the verification step warrants explicit budget and timeline.

Bottom line

QLDB's per-IO pricing model rewards careful schema and indexing design and penalizes naive deployment. For genuine ledger workloads with cryptographic verification requirements, the cost has historically been justifiable; for ledger-shaped workloads without those requirements, alternatives have always been cheaper. With the deprecation announcement, the calculation now also includes migration planning, and the right time to engage AWS on migration support is during the next contract conversation, not at the end of the sunset window.

For broader database cost strategy, see Aurora Serverless v2 Pricing (the most common QLDB migration target), DynamoDB On-Demand vs Provisioned for event-source alternatives, and AWS Pricing Changes History for the broader pattern of AWS pricing and lifecycle changes.