Day 23 wrapped up the original 11-day core service tour. Starting today, we move into the extended 7-day arc — services that didn't make the first pass but round out a genuinely complete picture of AWS. We're kicking it off back in the database world, with two specialized engines built for problems that neither relational databases nor DynamoDB handle particularly well: an immutable record of history, and deeply connected data.
Amazon QLDB (Quantum Ledger Database)
QLDB is a fully managed ledger database — purpose-built for applications that need a complete, verifiable, and unchangeable history of every change ever made to their data, not just the current state.
Here's the problem it solves that a regular database doesn't: in a typical relational database, when you update a row, the old value is simply gone (unless you built your own audit-log table to track it, which most teams don't do consistently, and which itself can be edited or deleted). For systems like financial transaction ledgers, supply chain tracking, or HR records, that's a real liability — you often need to prove not just what the current state is, but the exact, tamper-proof sequence of changes that got you there.
QLDB works by maintaining an append-only journal — every change is written as a new entry, and nothing is ever overwritten or deleted. Each entry is cryptographically chained to the one before it (similar in spirit to a blockchain's hash-linking), which means if anyone tried to alter a past entry, the cryptographic chain would break and the tampering would be immediately detectable. You can query both the current state of your data and its complete historical journey using PartiQL, a SQL-compatible query language that also understands QLDB's document-oriented, nested data.
A distinction worth being precise about, since it comes up constantly: QLDB is not a blockchain, even though the "immutable, cryptographically verified history" pitch sounds similar. Blockchain is built for scenarios where multiple parties who don't trust each other need to agree on a shared history without a central authority — that's why it needs distributed consensus, which is inherently slower and more complex. QLDB assumes a single trusted owner (your organization) maintaining the ledger; you don't need consensus across untrusted parties, just an unchangeable record that you yourself can't quietly alter after the fact. That trade-off makes QLDB dramatically faster and simpler to operate than running your own blockchain network, while still delivering the "tamper-evident history" property most companies actually need.
Amazon Neptune
Neptune is a fully managed graph database service — built specifically for data where the relationships between things matter as much as the things themselves.
The problem it solves: relational databases represent relationships through foreign keys and joins, and both DynamoDB and a typical relational schema get noticeably slower and more awkward as you ask questions that involve traversing many hops of connection — "find friends of friends of friends who also follow this person," or "find everyone connected to this fraud ring within 4 degrees." Each additional hop in a relational database means another join, and performance degrades fast. A graph database stores data explicitly as nodes (the entities — a person, a product, an account) and edges (the relationships connecting them — "follows," "bought," "works at") from the start, which makes traversing those connections dramatically faster, since the relationships are already stored as first-class, directly-connected data rather than something you have to reconstruct via a join at query time.
Neptune supports two different graph models and query languages, which is worth knowing since they solve slightly different problems: the property graph model, queried with Gremlin or openCypher, which is generally the more common choice for application-style graph use cases (social networks, recommendation engines, fraud detection); and the RDF (Resource Description Framework) model, queried with SPARQL, which is more common in knowledge-graph and semantic-web style use cases where you're representing formal, standardized relationships between concepts.
Common real-world use cases make the fit obvious: social network features (mutual friends, "people you may know"), recommendation engines (customers who bought X also bought Y, several hops deep), fraud detection (spotting rings of connected fraudulent accounts that wouldn't look suspicious individually), and knowledge graphs (representing and querying complex, interconnected facts).
Worth knowing beyond the fundamentals: Neptune supports high availability through read replicas spread across Availability Zones — up to 15, the same ceiling as Aurora — and automatic failover if the primary instance fails. It's also fully managed the way RDS and DynamoDB are: no manual patching or infrastructure management, and it scales storage automatically as your graph grows.
Why these two, specifically
QLDB and Neptune both exist because forcing certain data shapes into a relational or even a NoSQL key-value model creates real friction: QLDB because relational databases don't preserve history by default and can't cryptographically prove nothing was altered after the fact, and Neptune because relational joins get expensive fast once you're asking questions that are fundamentally about traversing relationships rather than looking up records. Neither is a replacement for RDS or DynamoDB in general — they're specialized tools for genuinely specialized shapes of problem.
Quick Recap Questions
- What does QLDB give you that a regular database with an audit-log table doesn't?
- Why is QLDB not a blockchain, despite both offering tamper-evident history?
- Why does a graph database traverse deep relationships faster than a relational database with joins?
- What's the difference between Neptune's property graph model and its RDF model, in terms of when you'd reach for each?
Where to read & follow
- Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
- GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
- LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/
Coming up next
| Day | Topic | Services |
|---|---|---|
| 25 | Security — Identity & Threat Protection | AWS Directory Service, CloudHSM, GuardDuty, Cognito |
Top comments (0)