AWS Specialty Databases: Neptune & QLDB
While RDS and DynamoDB handle the majority of application workloads, certain complex data relationships and integrity requirements demand purpose-built engines. For the SAA-C03 exam, you must distinguish between Amazon Neptune (Graph) and Amazon QLDB (Ledger).
The Analogy: Think of Neptune like a Social Media Web—it’s not about the individual user profiles, but the complex “likes,” “follows,” and “friends-of-friends” connections between them. Think of QLDB like a Notary’s Ledger—it is a permanent, unchangeable record of every transaction, where you can prove that no one “erased” or “altered” the history.
Core Concepts & Well-Architected Framework
1. Amazon Neptune (Graph Database)
What: A fully managed graph database service that supports popular graph models like Property Graph and W3C’s RDF.
Why (Well-Architected):
- Performance Efficiency: Queries billions of relationships with millisecond latency. Traditional SQL JOINs become exponentially slower as depth increases; Neptune stays performant.
- Reliability: High availability across 3 AZs with up to 15 read replicas.
2. Amazon QLDB (Quantum Ledger Database)
What: A fully managed ledger database that provides a transparent, immutable, and cryptographically verifiable transaction log.
Why (Well-Architected):
- Security: Built-in immutability. Data cannot be deleted or modified. A hashing chain (SHA-256) ensures data integrity.
- Operational Excellence: No need to manage a complex blockchain network when you only need a centralized, trusted authority.
Service Comparison
| Feature | Amazon Neptune | Amazon QLDB |
|---|---|---|
| Data Model | Graph (Nodes/Edges) | Ledger (Document-oriented) |
| Primary Use Case | Social Maps, Fraud Detection | Supply Chain, Systems of Record |
| Immutability | No (Standard CRUD) | Yes (Append-only Journal) |
| Query Language | Gremlin, SPARQL, openCypher | PartiQL (SQL-compatible) |
| Verification | N/A | Cryptographic (SHA-256) |
Scenario-Based Learning (Decision Matrix)
- IF the requirement is to track the complete history of vehicle registrations with zero possibility of tampering… THEN use QLDB.
- IF the requirement is to find “friends of friends who like Sushi” in a dataset of 10 million users… THEN use Neptune.
- IF you need a decentralized database where multiple parties don’t trust each other… THEN use Amazon Managed Blockchain (not QLDB).
- IF you need to detect credit card fraud by analyzing patterns between merchants and cardholders… THEN use Neptune.
Exam Tips: Golden Nuggets
- The “Central Authority” Keyword: If the exam mentions a “trusted central authority” needing a ledger, choose QLDB. If it mentions “decentralized” or “no central authority,” QLDB is a distractor—choose Blockchain.
- JOIN Pain: If a scenario describes a Relational Database (RDS) struggling with too many JOIN statements for connected data, Neptune is the architectural fix.
- Immutability: QLDB is the only database where “Delete” doesn’t actually remove the history from the journal. It is strictly append-only.
- Neptune Connectivity: Remember that Neptune is VPC-based. You cannot access it over the public internet without a VPN or Direct Connect.
Architectural Flow & Patterns
Key Services
Neptune: Highly available, Multi-AZ, supports Read Replicas. Best for Knowledge Graphs.
QLDB: Serverless-like scaling, no instances to manage. Best for Audit Logs.
Common Pitfalls
- Using Neptune for simple Key-Value lookups (use DynamoDB instead).
- Using QLDB for high-frequency temporary data (it’s permanent, cost will accumulate).
- Confusing QLDB with Blockchain (QLDB is centralized).
Quick Patterns
Identity Graph: Neptune links devices, cookies, and emails to a single user.
DMV Records: QLDB stores car ownership history to prevent title fraud.