QLDB vs. Blockchain
It's critical to understand that QLDB is not a blockchain.
| Feature | Amazon QLDB | Blockchain (e.g., Hyperledger, Ethereum) |
|---|---|---|
| Trust Model | Centralized. Owned and operated by a single, central trusted authority (AWS). | Decentralized. No central authority; trust is established via consensus algorithms across multiple nodes. |
| Performance | High. Can execute 2-3x more transactions than common blockchain frameworks. | Lower. Performance is limited by the need to achieve consensus across the network. |
| Data Mutability | Immutable. Data cannot be changed or deleted, only new versions can be added. | Immutable. Transactions are cryptographically linked in a distributed ledger. |
| Complexity | Simple. Standard database APIs and a familiar SQL-like query language. | Complex. Requires managing nodes, consensus mechanisms, and smart contracts. |
| Ideal Use Case | Applications that need a verifiable, complete history of data and are owned by a single entity (e.g., a company's internal audit system). | Applications that require trust between multiple, mutually untrusting parties without a central intermediary. |
Core Concepts & Architecture
QLDB's architecture is built around its journal-first design.
-
Ledger: The primary container for your data, consisting of the journal and tables.
-
Journal: The heart of QLDB. This is an append-only, immutable transaction log.
- Every committed data change is written to the journal first.
- Transactions are sequenced and cryptographically chained together using SHA-256 hashes, like a blockchain. This ensures that no record can be altered or deleted without breaking the entire chain.
-
Tables: These are the user-facing views of your data.
- Current State: Tables provide a queryable view of the latest version of your data, just like a traditional database.
- History: You can also query the full history of every change ever made to a document within a table.
-
Digest: A secure hash representation (a 256-bit hash value) of your ledger's entire change history at a point in time. You can export a digest and later use it to cryptographically verify that no unintended changes have been made to your ledger's history.
-
PartiQL: The SQL-compatible query language used to interact with QLDB tables for both current state and historical data.
Key Features
- Immutability: The journal-first, cryptographically chained architecture makes your data's history unchangeable.
- Verifiability: You can prove the integrity of your data's change history at any time using the digest and verification APIs.
- Serverless: QLDB automatically scales to support your application's workload. There are no read/write limits to configure or servers to manage.
- ACID Transactions: All transactions in QLDB are fully ACID-compliant (Atomicity, Consistency, Isolation, and Durability).
Common Use Cases
QLDB is ideal for any application that requires a complete, verifiable, and immutable record of all transactions—a "system of record."
- Finance & Banking: To track the complete history of all financial transactions (e.g., loans, payments, account changes) for auditing and accuracy.
- Insurance: To maintain a verifiable history of insurance claims, from initial filing to final settlement, preventing fraudulent alterations.
- Supply Chain: To track the full lifecycle of goods as they move through a supply chain, ensuring provenance and authenticity.
- Government & HR: To maintain tamper-proof records for vehicle registrations, licensing, or employee benefit changes.
Data Handling
- Export: QLDB does not have a traditional "backup" feature. Instead, you can export your journal data to Amazon S3. This export can serve as a backup or be used for analytics in other services like Amazon Athena or QuickSight.
Security
- Encryption by Default: All data is encrypted at rest and in transit using AWS-owned keys.
- Authentication: Access to the QLDB API is controlled via standard AWS IAM roles and policies. Requests are signed using AWS credentials.
- Network: Integrates with AWS PrivateLink to allow you to access QLDB from your VPC without traversing the public internet.
Important Limitations
- No Point-in-Time Restore (PITR): QLDB does not support the PITR feature found in databases like RDS. You must manage data recovery through journal exports.
- No Cross-Region Replication: QLDB does not have a built-in feature for cross-region replication.
- AWS-Owned Keys Only: You cannot use Customer-Managed Keys (CMKs) from AWS KMS to encrypt your ledger. Encryption is handled by AWS-owned keys.
Sources