Database engines with appropriate use cases (for example, heterogeneous migrations, homogeneous migrations)

Task Statement 3.3: Determine high-performing database solutions.

📘AWS Certified Solutions Architect – (SAA-C03)


1. What is a Database Engine?

A database engine is the core software that stores, manages, and retrieves data.

Examples:

  • Relational engines (SQL-based)
  • Non-relational engines (NoSQL)
  • In-memory engines
  • Graph, time-series, and ledger databases

In AWS, these engines are provided through managed services such as:

  • Amazon Web Services database services

2. Types of Database Engines and Their Use Cases


A. Relational Databases (SQL)

Supported by:

  • Amazon RDS
  • Amazon Aurora

Examples of engines:

  • MySQL
  • PostgreSQL
  • MariaDB
  • Oracle
  • SQL Server

Key Characteristics:

  • Structured data (tables with rows and columns)
  • Uses SQL queries
  • Supports ACID transactions (important for consistency)

Use Cases:

  • Applications requiring strong consistency
  • Systems with structured schemas
  • Workloads with complex queries and joins

IT-Based Example:

A backend system storing:

  • User accounts
  • Transaction records
  • Access logs

This system requires:

  • Data integrity
  • Relationships between tables
  • Reliable transactions

B. NoSQL Databases (Non-Relational)

Supported by:

  • Amazon DynamoDB

Key Characteristics:

  • Schema-less (flexible structure)
  • High scalability
  • Low latency
  • Handles large amounts of unstructured data

Types:

  • Key-value
  • Document
  • Wide-column

Use Cases:

  • High-traffic applications
  • Real-time data processing
  • Applications with rapidly changing data structure

IT-Based Example:

A system storing:

  • Session data
  • User activity logs
  • API request metadata

This system requires:

  • Fast read/write
  • Massive scaling
  • Flexible data format

C. In-Memory Databases

Supported by:

  • Amazon ElastiCache
  • Amazon MemoryDB for Redis

Key Characteristics:

  • Data stored in RAM
  • Extremely low latency (microseconds)
  • Used for caching and real-time processing

Use Cases:

  • Caching frequently accessed data
  • Session storage
  • Leaderboards or counters

IT-Based Example:

An application caches:

  • Frequently accessed query results
  • Authentication tokens

This reduces load on the primary database.


D. Data Warehouse (Analytics)

Supported by:

  • Amazon Redshift

Key Characteristics:

  • Optimized for analytical queries (OLAP)
  • Handles large datasets
  • Columnar storage

Use Cases:

  • Reporting systems
  • Business intelligence
  • Data analysis across large datasets

IT-Based Example:

A system analyzing:

  • Logs from multiple applications
  • Historical usage data
  • Performance metrics

E. Graph Databases

Supported by:

  • Amazon Neptune

Key Characteristics:

  • Stores relationships between data
  • Optimized for connected data queries

Use Cases:

  • Relationship mapping
  • Network analysis
  • Dependency tracking

IT-Based Example:

A system mapping:

  • Service dependencies
  • API relationships
  • Access permissions between services

F. Time-Series Databases

Supported by:

  • Amazon Timestream

Key Characteristics:

  • Optimized for time-based data
  • Handles large streams of timestamped records

Use Cases:

  • Monitoring systems
  • Metrics collection
  • Event tracking

IT-Based Example:

A monitoring system storing:

  • CPU usage
  • Memory metrics
  • Request latency over time

G. Ledger Databases

Supported by:

  • Amazon QLDB

Key Characteristics:

  • Immutable (cannot be changed)
  • Cryptographically verifiable history

Use Cases:

  • Audit systems
  • Change tracking
  • Compliance requirements

IT-Based Example:

A system tracking:

  • Configuration changes
  • Access history
  • Security logs

3. Choosing the Right Database Engine (Exam Focus)

You should select based on:

1. Data Structure

  • Structured → Relational (RDS, Aurora)
  • Unstructured → NoSQL (DynamoDB)

2. Performance Needs

  • Ultra-low latency → In-memory (ElastiCache)
  • Analytics → Redshift

3. Scalability

  • Massive scale → DynamoDB
  • Moderate scale → RDS

4. Relationships

  • Complex joins → Relational
  • Relationship-heavy → Graph (Neptune)

5. Data Access Pattern

  • Read-heavy → Cache + Read replicas
  • Write-heavy → DynamoDB

4. Database Migration Types (VERY IMPORTANT)


A. Homogeneous Migration

Definition:

Migration between same database engines

Examples:

  • MySQL → MySQL
  • PostgreSQL → PostgreSQL

AWS Tools:

  • AWS Database Migration Service (DMS)

Characteristics:

  • Easier and faster
  • Minimal changes required
  • Schema remains the same

Use Case:

Moving an on-premises database to AWS without changing engine


B. Heterogeneous Migration

Definition:

Migration between different database engines

Examples:

  • Oracle → PostgreSQL
  • SQL Server → MySQL

AWS Tools:

  • AWS Database Migration Service
  • AWS Schema Conversion Tool (SCT)

Characteristics:

  • More complex
  • Requires schema conversion
  • May need application changes

Use Case:

Modernizing legacy systems by switching to open-source or cloud-native databases


5. Migration Strategy Flow (Exam Tip)

For heterogeneous migration:

  1. Use Schema Conversion Tool (SCT)
    → Converts schema (tables, indexes, etc.)
  2. Use Database Migration Service (DMS)
    → Migrates actual data

6. Key Exam Tips (Must Remember)

1. Aurora vs RDS

  • Aurora = higher performance, cloud-optimized
  • RDS = standard managed relational database

2. DynamoDB

  • Serverless
  • Best for unpredictable traffic
  • No joins

3. ElastiCache

  • Used with databases, not as replacement (mostly)
  • Improves read performance

4. Redshift

  • Not for transactions
  • Only for analytics (OLAP)

5. Migration Keywords

  • Same engine → Homogeneous → Easy
  • Different engine → Heterogeneous → Use SCT + DMS

7. Quick Summary Table

RequirementBest Choice
Structured dataRDS / Aurora
High scalabilityDynamoDB
Ultra-fast readsElastiCache
AnalyticsRedshift
RelationshipsNeptune
Time-based dataTimestream
Audit logsQLDB
Buy Me a Coffee