AWS offers 15+ managed database services. Each is purpose-built for specific data models and access patterns. Choosing wrong means either fighting the database's design (performance problems) or over-engineering a simple workload (cost problems).
The key insight: start with your access patterns, not the database. How will data be read and written? What queries are critical? What's the read/write ratio? The answers point directly to the right service.
This guide covers every AWS database service, organized by data model, with a decision framework that gets you to the right choice fast.
The AWS Database Landscape
┌─────────────────────────────────────────────────────────────────────┐
│ AWS DATABASE SERVICES │
├─────────────────────────────────────────────────────────────────────┤
│ RELATIONAL (SQL) │
│ RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB) | Aurora │
├─────────────────────────────────────────────────────────────────────┤
│ KEY-VALUE / DOCUMENT (NoSQL) │
│ DynamoDB │
├─────────────────────────────────────────────────────────────────────┤
│ IN-MEMORY (Caching / Real-Time) │
│ ElastiCache (Redis/Valkey, Memcached) | MemoryDB for Redis │
├─────────────────────────────────────────────────────────────────────┤
│ GRAPH │
│ Neptune │
├─────────────────────────────────────────────────────────────────────┤
│ TIME SERIES │
│ Timestream │
├─────────────────────────────────────────────────────────────────────┤
│ WIDE COLUMN │
│ Keyspaces (Cassandra-compatible) │
├─────────────────────────────────────────────────────────────────────┤
│ SEARCH │
│ OpenSearch Service │
├─────────────────────────────────────────────────────────────────────┤
│ LEDGER │
│ QLDB (Quantum Ledger Database) │
├─────────────────────────────────────────────────────────────────────┤
│ DATA WAREHOUSE │
│ Redshift │
├─────────────────────────────────────────────────────────────────────┤
│ VECTOR (AI/ML) │
│ Aurora (pgvector) | OpenSearch | MemoryDB | Neptune Analytics │
└─────────────────────────────────────────────────────────────────────┘
The Decision Flowchart
START
│
├── Need SQL, joins, transactions, complex queries?
│ ├── High performance, auto-scaling, global? → Aurora
│ └── Standard workload, specific engine (Oracle/SQL Server)? → RDS
│
├── Need key-value or simple document access at any scale?
│ └── DynamoDB
│
├── Need microsecond latency caching?
│ ├── Cache-aside pattern (volatile)? → ElastiCache
│ └── Need durability (primary datastore)? → MemoryDB
│
├── Need relationship traversal (social graph, fraud, recommendations)?
│ └── Neptune
│
├── Need time-series data (IoT, metrics, logs)?
│ └── Timestream
│
├── Need full-text search, log analytics?
│ └── OpenSearch
│
├── Need analytics on petabytes (BI, reporting)?
│ └── Redshift
│
├── Need vector similarity search (AI/RAG)?
│ └── Aurora pgvector / OpenSearch / MemoryDB
│
└── Need immutable, cryptographically verifiable ledger?
└── QLDB
Relational Databases: RDS vs Aurora
Amazon RDS
What: Managed relational database for MySQL, PostgreSQL, MariaDB, Oracle, SQL Server.
AWS manages: Patching, backups, Multi-AZ failover, monitoring.
You manage: Instance sizing, parameter tuning, schema design, query optimization.
Key features:
- Multi-AZ: synchronous standby for HA (automatic failover ~60 seconds)
- Read Replicas: up to 15 (async replication) for read scaling
- Automated backups: point-in-time recovery (35-day window)
- Storage auto-scaling: up to 64 TiB
Amazon Aurora
What: AWS-rebuilt MySQL/PostgreSQL with cloud-native storage architecture. Compatible at the wire-protocol level (drop-in replacement).
Why Aurora over RDS:
| Feature | RDS | Aurora |
|---|---|---|
| Performance | 1x (standard engine) | 3-5x MySQL, 3x PostgreSQL |
| Storage | EBS (single AZ) | Distributed across 3 AZs (6 copies) |
| Storage limit | 64 TiB | 128 TiB (auto-grows) |
| Failover | ~60 seconds | ~30 seconds (with Aurora Replicas) |
| Read replicas | Up to 15 (async) | Up to 15 (same storage, <10ms lag) |
| Backtrack | ❌ | ✅ (rewind to point in time without restore) |
| Global Database | ❌ | ✅ (<1 second cross-region replication) |
| Serverless | ❌ | ✅ (Aurora Serverless v2 — scales to zero) |
| Multi-master | ❌ | ✅ (Aurora DSQL — distributed SQL, new) |
When to Choose RDS vs Aurora
| Choose RDS when... | Choose Aurora when... |
|---|---|
| Need Oracle or SQL Server | MySQL or PostgreSQL workload |
| Budget-constrained (RDS is cheaper for small instances) | Need high availability (<30s failover) |
| Simple, low-traffic application | Read-heavy workload (leverage replicas on shared storage) |
| Specific engine version required | Need global database (cross-region DR) |
| Need serverless (variable/unpredictable traffic) | |
| Need to scale storage beyond 64 TiB |
Aurora Serverless v2
Scales compute automatically (0.5 to 256 ACUs) based on demand. You pay per ACU-hour consumed.
Best for: Dev/test environments, variable workloads, new applications with unknown traffic patterns.
Not for: Steady high-traffic production (provisioned instances are cheaper when utilization is consistently high).
DynamoDB: NoSQL at Any Scale
What: Fully managed key-value and document database. Single-digit millisecond performance at any scale.
When to Use DynamoDB
- Key-value or simple document access patterns
- Extreme scale (millions of requests/second)
- Predictable, consistent latency requirements
- Serverless architecture (scales to zero with on-demand mode)
- Global applications (Global Tables for multi-region active-active)
When NOT to Use DynamoDB
- Complex queries with joins, aggregations, ad-hoc SQL
- Data model that requires normalization and relational integrity
- Analytics/reporting (use Redshift or Athena instead)
- Small dataset with complex query needs (Aurora is simpler)
DynamoDB Key Design Decisions
| Decision | Options |
|---|---|
| Capacity mode | On-Demand (unpredictable traffic, pay per request) vs Provisioned (predictable, cheaper at scale) |
| Primary key | Partition key only (unique lookup) vs Partition + Sort key (range queries within partition) |
| Global Tables | Multi-region active-active replication (near-zero RPO) |
| DAX | In-memory cache for DynamoDB (microsecond reads for hot data) |
| Streams | Capture changes for event-driven processing (CDC) |
DynamoDB Pricing Reality
On-Demand: $1.25 per million write requests, $0.25 per million reads
Provisioned: ~$0.00065 per WCU/hour, ~$0.00013 per RCU/hour
Storage: $0.25/GB/month
Example: 10M reads + 1M writes per day
On-Demand: ~$10/day = $300/month
Provisioned: ~$120/month (60% cheaper at consistent load)
ElastiCache vs MemoryDB: Caching and Real-Time
ElastiCache (Redis/Valkey or Memcached)
Use for: Caching layer in front of databases. Session storage. Leaderboards. Real-time analytics.
| Feature | Redis/Valkey | Memcached |
|---|---|---|
| Data structures | Rich (strings, hashes, lists, sets, sorted sets) | Simple key-value only |
| Persistence | Optional (snapshot + AOF) | None (volatile) |
| Replication | Yes (read replicas, Multi-AZ) | No replication |
| Pub/Sub | Yes | No |
| Cluster mode | Yes (horizontal sharding) | Yes (simple sharding) |
| Use case | Primary cache + data structures | Simple caching only |
MemoryDB for Redis
What: Redis-compatible, durable, in-memory database. Unlike ElastiCache (which is a cache), MemoryDB is a primary database that happens to be in-memory.
Key difference: MemoryDB writes to a distributed transaction log before acknowledging — data survives node failures. ElastiCache can lose data on failover.
Use MemoryDB when: You need microsecond reads AND durability (session store as source of truth, real-time user profiles, gaming state).
Purpose-Built Databases
Amazon Neptune (Graph)
Use for: Relationship-heavy data where traversals are the primary query pattern.
- Social networks (friend-of-friend queries)
- Fraud detection (link analysis)
- Recommendation engines (collaborative filtering)
- Knowledge graphs (entity relationships)
- Network topology (impact analysis)
NOT for: Simple lookups, transactional data, analytics. If you're not doing multi-hop traversals, you don't need a graph database.
Amazon Timestream (Time Series)
Use for: Time-stamped data that's primarily queried by time range.
- IoT sensor data
- Application/infrastructure metrics
- Financial market data (ticks)
- Fleet/device telemetry
Why over DynamoDB: Built-in time-based retention tiers (hot → cold → archive), time-series functions (interpolation, smoothing, aggregation), and automatic data lifecycle management.
Amazon Keyspaces (Cassandra)
Use for: Teams with existing Cassandra workloads wanting managed service. Wide-column data model for write-heavy workloads with predictable access patterns.
Amazon OpenSearch (Search + Analytics)
Use for: Full-text search, log analytics, application search, observability data.
- Powers CloudWatch Log Insights behind the scenes
- Kibana/OpenSearch Dashboards for visualization
- Vector search for AI/RAG applications
Amazon QLDB (Ledger)
Use for: Immutable, cryptographically verifiable transaction history.
- Financial transactions requiring audit trail
- Supply chain provenance tracking
- Regulatory compliance (tamper-proof records)
Amazon Redshift (Data Warehouse)
Use for: Analytical queries on large datasets (petabytes). BI reporting, data warehousing, complex aggregations across millions of rows.
NOT for: OLTP (transactional workloads) — use Aurora or DynamoDB instead.
Vector Databases for AI/RAG
With generative AI, vector similarity search is a new access pattern. AWS options:
| Service | Vector Capability | Best For |
|---|---|---|
| Aurora PostgreSQL (pgvector) | Extension on existing Aurora | Teams already on Aurora, moderate scale |
| OpenSearch | k-NN plugin | Large-scale similarity search + hybrid text/vector |
| MemoryDB | Vector search support | Ultra-low latency vector retrieval |
| Neptune Analytics | Graph + vector | Knowledge graph with semantic search |
| Bedrock Knowledge Base | Managed (any backend) | Easiest path — managed vector storage |
Multi-Database Architecture Patterns
Pattern 1: CQRS (Command Query Responsibility Segregation)
Writes → Aurora (source of truth, transactions)
Reads → ElastiCache (cached hot data) + DynamoDB (materialized views)
Pattern 2: Event Sourcing + Materialized Views
Events → DynamoDB (event store) → Streams → Lambda →
├── OpenSearch (search index)
├── ElastiCache (real-time aggregations)
└── Redshift (analytics)
Pattern 3: Polyglot Persistence
User Profiles → DynamoDB (key-value, high scale)
Product Catalog → Aurora (relational, complex queries)
Recommendations → Neptune (graph traversal)
Session State → ElastiCache (microsecond, volatile)
Search → OpenSearch (full-text)
Analytics → Redshift (OLAP, BI)
Common Mistakes
| Mistake | Problem | Fix |
|---|---|---|
| DynamoDB for ad-hoc SQL queries | Expensive scans, poor performance | Use Aurora or Athena |
| Aurora for simple key-value access | Over-engineered, slower than DynamoDB | Use DynamoDB |
| ElastiCache as primary datastore | Data loss on failover | Use MemoryDB if durability needed |
| Single database for everything | One size fits none | Polyglot persistence (right DB per access pattern) |
| Redshift for OLTP | Terrible latency for single-row reads | Use Aurora or DynamoDB |
| Ignoring connection pooling (Aurora) | Connection exhaustion under load | Use RDS Proxy |
| DynamoDB without understanding key design | Hot partitions, throttling | Design partition key for even distribution |
Cost Comparison (Typical Web App)
| Service | Starting Cost (dev) | Production Estimate |
|---|---|---|
| RDS db.t4g.medium | ~$50/month | ~$200-500/month (Multi-AZ) |
| Aurora Serverless v2 (min 0.5 ACU) | ~$45/month | Scales with usage |
| Aurora Provisioned (db.r6g.large) | ~$180/month | ~$400-800/month (Multi-AZ + replicas) |
| DynamoDB (On-Demand, light) | ~$5-25/month | Scales per request |
| ElastiCache (cache.t4g.small) | ~$25/month | ~$100-300/month (Multi-AZ) |
| OpenSearch (t3.small.search) | ~$35/month | ~$200-500/month (Multi-AZ) |
Summary
AWS database selection is driven by access patterns, not features:
| Access Pattern | Database |
|---|---|
| SQL, joins, transactions, complex queries | Aurora (or RDS for Oracle/SQL Server) |
| Key-value lookups at massive scale | DynamoDB |
| Microsecond caching (volatile) | ElastiCache |
| Microsecond reads (durable) | MemoryDB |
| Relationship traversal (graph) | Neptune |
| Time-series data | Timestream |
| Full-text search | OpenSearch |
| Analytical queries (BI) | Redshift |
| Vector similarity (AI/RAG) | Aurora pgvector or OpenSearch |
| Immutable audit ledger | QLDB |
The guiding principle: One database rarely fits all access patterns. Use purpose-built databases for each pattern (polyglot persistence), connected by event-driven synchronization.
Alpesh Kumbhare is an AWS Architect at Atos, specializing in AWS data architecture and cloud infrastructure automation. Connect on LinkedIn.
Top comments (0)