RDS DynamoDB ElastiCache
LearningTree · AWS · Database

AWS Database —
The Right DB for Every Problem

Not a list of services — a decision framework. AWS has 12+ database services. Understanding when to choose each — relational, NoSQL, in-memory, graph, analytics, time-series — is the real skill for both production and AWS certification exams.

The AWS Database Universe

Every application has a data model — tables, documents, key-value pairs, graphs, time-series. AWS provides a purpose-built database for each model. The secret: never force a relational database to do a graph job, and never run analytics on an OLTP database.

How AWS Databases fit together in a modern application
Application / API ElastiCache MemoryDB μs latency cache/db RDS / Aurora Relational OLTP SQL, ACID, ms latency DynamoDB NoSQL Key-Value Serverless, any scale Neptune Graph DB Nodes + edges Redshift Analytics OLAP Petabyte warehouse SPECIALTY DATABASES Timestream QLDB DocumentDB Keyspaces RDS Custom RDS on VMware
Database Categories — What Each Type Does
Category Service Data Model One-Liner
① Relational (OLTP)RDSTables, SQL, ACIDStandard structured-data workloads
① Relational (Cloud)AuroraTables, SQL, ACIDRDS ×5 perf, multi-AZ native, serverless
② NoSQL / Key-ValueDynamoDBKey-value & documentServerless, ms latency, any scale
③ In-Memory (Cache)ElastiCacheKey-value (RAM)Sub-ms reads, reduce DB load
③ In-Memory (Durable)MemoryDB for RedisKey-value (RAM + log)Redis speed + full durability
④ GraphNeptuneNodes + edgesRelationships, social, fraud detection
⑤ Analytics (OLAP)RedshiftColumnar SQLData warehouse, petabyte analytics
⑥ Time-SeriesTimestreamTimestamped rowsIoT sensors, metrics, logs
⑦ LedgerQLDBImmutable journalCryptographic audit trail
⑧ DocumentDocumentDBJSON documentsMongoDB-compatible, flexible schema
⑨ Wide-ColumnKeyspacesPartition + columnCassandra-compatible, high-write
🧠 Key Insight

These services are not alternatives — they solve different problems. A production system typically uses multiple: RDS/Aurora (OLTP) + ElastiCache (caching) + DynamoDB (session/NoSQL) + Redshift (analytics).

Decision Guide — When to Use What
You Need… Use Why
SQL, ACID, complex joins, structured dataRDS / AuroraRow-based OLTP, familiar SQL interface
MySQL/Postgres with higher perf + native HAAurora5× MySQL / 3× PG speed, 6 copies across 3 AZs, auto-scaling storage
Serverless NoSQL, ms latency, unpredictable scaleDynamoDBSingle-digit ms, unlimited scale, access-pattern design
Sub-ms reads, reduce DB load, session storageElastiCacheRedis or Memcached in-memory; cache reads, not a primary DB
Redis as a durable primary databaseMemoryDB for RedisRedis speed + Multi-AZ transaction log, zero data loss on failover
Social network, fraud detection, recommendationNeptuneGraph traversal is O(n); SQL JOINs are O(nยณ) for multi-hop
Analytics, BI dashboards, petabyte queriesRedshiftColumnar, MPP, Spectrum for S3, Zero-ETL from RDS
IoT sensor data, metrics, time-stamped eventsTimestreamPurpose-built, hot→warm→cold auto-tiering, 10× cheaper
Immutable audit trail, financial ledgerQLDBCryptographic hash chain; nothing can be deleted or altered
JSON documents, MongoDB-compatible APIDocumentDBWire-protocol compatible; Aurora-style storage underneath
Cassandra workloads on AWSKeyspacesDrop-in Cassandra replacement, serverless, on-demand pricing
Oracle/SQL Server + need OS-level accessRDS CustomRDS automation + SSH to EC2, install agents, custom patches
Architecture Patterns
4 Common Database Patterns — OLTP ยท Serverless ยท Analytics ยท Graph
PATTERN 1: 3-Tier App ALB → EC2 / ECS ↓ ElastiCache (cache) ↓ RDS / Aurora (OLTP) Enterprise OLTP stack PATTERN 2: Serverless API Gateway → Lambda ↓ DynamoDB Zero infra management Pay per request PATTERN 3: Analytics RDS → Zero-ETL → Redshift ↓ QuickSight / BI Tools No ETL pipeline needed Near-real-time OLAP PATTERN 4: Graph App → Neptune Friend-of-friend queries Fraud ring detection Relationship traversal PRODUCTION STACK (multi-database architecture) Aurora Primary OLTP ElastiCache Query cache DynamoDB Session / NoSQL Redshift Analytics OLAP Neptune Graph queries Timestream / QLDB Time-series / Ledger
Exam Insights

🎯 Exam Keywords → Service

  • “SQL, ACID, relational, transactions” → RDS / Aurora
  • “higher performance MySQL/PG, multi-AZ native” → Aurora
  • “global database, cross-region reads with <1s lag” → Aurora Global Database
  • “serverless NoSQL, single-digit ms, any scale” → DynamoDB
  • “DynamoDB stream, process changes in real-time” → DynamoDB Streams + Lambda
  • “sub-ms, cache, session storage, reduce DB calls” → ElastiCache
  • “durable Redis, persistent in-memory, no data loss” → MemoryDB for Redis
  • “social network, fraud detection, relationship traversal” → Neptune
  • “data warehouse, OLAP, petabyte analytics, BI” → Redshift
  • “RDS to analytics without ETL pipeline” → Redshift Zero-ETL
  • “query S3 data with SQL” → Redshift Spectrum
  • “IoT sensor, time-series, metrics, timestamps” → Timestream
  • “immutable audit trail, financial ledger, cryptographic history” → QLDB
  • “decentralized blockchain, multiple parties, trustless” → Managed Blockchain (NOT QLDB)
  • “MongoDB-compatible, JSON documents, flexible schema” → DocumentDB
  • “Cassandra-compatible, wide-column, migrate Cassandra” → Keyspaces
  • “Oracle/SQL Server + OS access, custom agent, SSH to host” → RDS Custom

⚠️ Common Exam Traps

  • OLTP ≠ OLAP — never run analytics on RDS; never run transactions on Redshift
  • ElastiCache = cache (data loss acceptable on failure); MemoryDB = durable database (no data loss)
  • QLDB ≠ Managed Blockchain — QLDB is centralized (you own it); Blockchain is decentralized
  • DynamoDB DAX ≠ ElastiCache — DAX is DynamoDB-specific only; ElastiCache is general-purpose
  • Aurora Multi-AZ ≠ Aurora Global — Multi-AZ = same-region failover; Global = cross-region reads + DR
  • RDS read replicas are async (eventual consistency); Aurora reader nodes are near-sync (in-cluster)
  • DocumentDB is MongoDB wire-protocol compatible but runs Aurora storage — not a MongoDB fork
  • Neptune = graph (relationship-first); don't use RDS JOINs for multi-hop traversals at scale
  • Redshift is columnar (great for SELECT/SUM/GROUP BY); RDS is row-based (great for OLTP inserts)
  • RDS Custom = managed + OS access (Oracle/SQL Server only); standard RDS = fully managed, no OS access
Explore Each Service