Start with access patterns
Database selection begins with data model, query patterns, consistency, latency, throughput, scaling, and recovery objectives, not with a service name.
| Requirement | Candidate |
|---|---|
| Relational model, SQL, joins | RDS / Aurora |
| Key-value/document, single-digit-ms latency, horizontal scale | DynamoDB |
| Cassandra CQL compatibility | Keyspaces |
| MongoDB-compatible documents | DocumentDB |
| Graph relationships | Neptune |
| Time series | Timestream |
| Microsecond cache, sessions, leaderboard | ElastiCache |
Frequent questions
- RDS Multi-AZ is for availability, not read scale; read replicas scale reads and can be promoted.
- Aurora’s writer endpoint handles writes; its reader endpoint is a common entry for reads.
- RDS Proxy pools connections for Lambda connection storms; it is not a query cache.
- A DynamoDB partition key controls distribution; GSIs add access patterns, while DAX caches eventually consistent reads.
- Cache-aside and write-through need an invalidation strategy, TTL, and stampede protection.
- Backup/PITR, Multi-AZ, and cross-Region DR are different capabilities.
Answer structure
Data model → access pattern → capacity and partitioning → HA → backup/DR → security → monitoring and cost.
Remember
Describe data and queries before naming a service. Availability, read scaling, caching, and backup are four separate problems.