Task Statement 3.3: Determine high-performing database solutions.
📘AWS Certified Solutions Architect – (SAA-C03)
1. Why Choosing the Right Database Type Matters
In AWS, choosing the correct database type is critical because it affects:
- Performance (speed and latency)
- Scalability (handling growth)
- Cost efficiency
- Availability and durability
- Complexity of application design
👉 Exam Tip:
Most questions test whether you can match:
- Workload type → Correct database type
2. Main Database Categories in AWS
You must first understand the two core database types:
2.1 Relational Databases (SQL)
Example:
- Amazon Aurora
- Amazon RDS (MySQL, PostgreSQL, etc.)
Key Characteristics:
- Structured data (tables, rows, columns)
- Fixed schema (predefined structure)
- Supports SQL queries
- ACID transactions (high consistency)
When to Use:
Use relational databases when:
- Data relationships are important
- You need joins (multiple tables linked together)
- Strong consistency is required
- Transactions must be reliable (no partial updates)
Common IT Use Cases:
- User account systems
- Financial transaction systems
- ERP or CRM systems
- Backend systems with complex queries
2.2 Non-Relational Databases (NoSQL)
Example:
- Amazon DynamoDB
Key Characteristics:
- Flexible schema (no fixed structure)
- Key-value or document-based
- Extremely scalable
- High performance at any scale
When to Use:
Use NoSQL when:
- You need massive scalability
- Data structure is flexible or changing
- Low-latency access is required
- Simple queries (no joins)
Common IT Use Cases:
- Session storage
- Real-time analytics
- User activity tracking
- High-traffic web applications
3. Deep Dive: Amazon Aurora vs Amazon DynamoDB
This is a very important exam comparison.
3.1 Amazon Aurora (Relational)
Overview:
- Fully managed relational database
- Compatible with MySQL and PostgreSQL
- Designed for high performance
Key Features:
- Up to 5x faster than MySQL
- Automatic storage scaling
- Multi-AZ high availability
- Read replicas for scaling reads
Strengths:
- Complex queries supported
- Strong consistency
- ACID compliance
- Good for structured data
Limitations:
- Not ideal for massive, unpredictable scaling
- Requires schema design
3.2 Amazon DynamoDB (NoSQL)
Overview:
- Fully managed serverless NoSQL database
- Key-value and document store
Key Features:
- Single-digit millisecond latency
- Automatic scaling (no capacity planning)
- Fully serverless
- Built-in high availability
Strengths:
- Handles millions of requests per second
- No schema required
- Ideal for unpredictable workloads
- Global tables for multi-region
Limitations:
- No joins
- Limited querying flexibility
- Requires access pattern design
4. Aurora vs DynamoDB – Quick Comparison
| Feature | Aurora | DynamoDB |
|---|---|---|
| Type | Relational (SQL) | NoSQL (Key-value) |
| Schema | Fixed | Flexible |
| Queries | Complex (joins supported) | Simple (no joins) |
| Scaling | Vertical + read replicas | Fully automatic |
| Latency | Low | Ultra-low |
| Transactions | Strong (ACID) | Limited (but supported) |
| Best For | Structured data | Massive scale workloads |
👉 Exam Tip:
If the question mentions:
- “complex queries / joins” → Aurora
- “millions of requests / low latency / serverless” → DynamoDB
5. Other AWS Database Types (Must Know)
Even though Aurora vs DynamoDB is most common, you must recognize others:
5.1 Key-Value Database
- Example: Amazon DynamoDB
- Ultra-fast lookups using a primary key
5.2 Document Database
- Example: Amazon DocumentDB
- Stores JSON-like documents
5.3 In-Memory Database
- Example: Amazon ElastiCache
Use Cases:
- Caching frequently accessed data
- Reducing database load
- Real-time applications
5.4 Graph Database
- Example: Amazon Neptune
Use Cases:
- Relationship-heavy data
- Recommendation systems
- Fraud detection
5.5 Data Warehouse
- Example: Amazon Redshift
Use Cases:
- Analytics and reporting
- Large-scale data processing
6. Decision-Making Strategy (Exam Shortcut)
When you see a question, follow this thinking process:
Step 1: Identify Data Type
- Structured → Relational → Aurora
- Flexible / unknown → NoSQL → DynamoDB
Step 2: Check Query Complexity
- Complex queries / joins → Aurora
- Simple key-based access → DynamoDB
Step 3: Evaluate Scale
- Moderate scaling → Aurora
- Massive, unpredictable scaling → DynamoDB
Step 4: Check Performance Needs
- Low latency → DynamoDB
- Strong consistency → Aurora
Step 5: Look for Keywords
| Keyword | Choose |
|---|---|
| Transactions | Aurora |
| Joins | Aurora |
| Serverless DB | DynamoDB |
| Millisecond latency | DynamoDB |
| Flexible schema | DynamoDB |
7. Common Exam Scenarios
Scenario 1:
- Needs SQL queries + joins
✅ Choose: Amazon Aurora
Scenario 2:
- High traffic + unpredictable workload
✅ Choose: Amazon DynamoDB
Scenario 3:
- Requires strict consistency and transactions
✅ Choose: Amazon Aurora
Scenario 4:
- Requires ultra-fast reads with simple access patterns
✅ Choose: Amazon DynamoDB
Scenario 5:
- Needs caching to improve performance
✅ Choose: Amazon ElastiCache
8. Important Mistakes to Avoid
❌ Choosing DynamoDB when joins are required
❌ Choosing Aurora for extremely high-scale key-value workloads
❌ Ignoring access patterns in DynamoDB
❌ Forgetting that DynamoDB is serverless
9. Final Exam Summary (Must Remember)
- Aurora = Relational + Structured + SQL + Transactions
- DynamoDB = NoSQL + Scalable + Serverless + Low latency
- Always match:
Workload → Database type → AWS service
