Pick storage by access pattern—not hype. Relational OLTP, document, key-value, cache, and warehouse workloads map to different AWS services.
Decision matrix
| Need | Often choose |
|---|---|
| SQL joins, ACID, reporting | RDS PostgreSQL / Aurora |
| Massive key-value scale | DynamoDB |
| Sub-ms session cache | ElastiCache Redis |
| Ad hoc analytics at petabyte scale | Redshift / Athena (awareness) |
| Flexible JSON documents | DynamoDB or RDS JSONB |
Polyglot persistence
Real systems mix services: PostgreSQL for orders, DynamoDB for click streams, Redis for sessions, S3 for exports. Align with skills from SQL and app frameworks like Django.
Migration awareness
AWS DMS (Database Migration Service) helps move on-prem databases to RDS with minimal downtime—plan schema compatibility and cutover windows.
Important interview questions and answers
- Q: When DynamoDB over RDS?
A: Predictable key access at huge scale with minimal join needs and ops desire for serverless scaling. - Q: When PostgreSQL on RDS?
A: Relational integrity, complex queries, mature ORM ecosystems.
Self-check
- Match: session store → which AWS service?
- When would you pick Aurora over standard RDS PostgreSQL?
Tip: Match database to access pattern—do not force every workload into DynamoDB or RDS.
Interview prep
- Sessions?
ElastiCache Redis for shared fast session storage.
- Relational OLTP?
RDS PostgreSQL or Aurora for SQL, joins, and ACID transactions.