2.4.1. Evaluating Database Options (RDS, Aurora, DynamoDB, Redshift, DocumentDB, ElastiCache, Neptune, QLDB, Timestream)

💡 First Principle: Optimal database selection is achieved by matching the data model, query patterns, and consistency requirements of a workload to the specialized capabilities of a purpose-built database service.

Scenario: A new social media application needs to store user profiles (flexible schema, high read/write volume), friend connections (complex relationships), and a history of all user actions (immutable and verifiable).

AWS provides a highly diversified portfolio of managed database services, each optimized for specific workloads.

• "Amazon RDS (Relational Database Service)": A managed service that simplifies setting up, operating, and scaling relational databases in the cloud. Managed relational databases ("MySQL", "PostgreSQL", "SQL Server", "Oracle", "MariaDB").
  • Why: Traditional "OLTP" workloads, strong "ACID" compliance. Reduces operational overhead of self-managed DBs.
• "Amazon Aurora": "MySQL" and "PostgreSQL"-compatible relational database built for the cloud.
  • Why: 5x faster than "MySQL", 3x faster than "PostgreSQL". Highly available, auto-scaling storage, high durability. Ideal for high-performance relational needs.
• "Amazon DynamoDB": A fully managed "NoSQL" key-value and document database.
  • Why: High-performance, highly scalable, single-digit millisecond latency at any scale. Ideal for mobile, web, gaming, "IoT", microservices, and applications needing flexible schema with high throughput.
• "Amazon Redshift": A fast, fully managed, petabyte-scale data warehouse.
  • Why: "OLAP" workloads, large-scale analytics, business intelligence.
• "Amazon DocumentDB": A managed "MongoDB"-compatible document database.
  • Why: For "MongoDB" workloads, offers scalability and enterprise features.
• "Amazon ElastiCache": An in-memory caching service. Supports "Redis" and "Memcached".
  • Why: Reduces database load, improves application response times for frequently accessed data.
• "Amazon Neptune": A fully managed graph database.
  • Why: For highly connected datasets (social networks, recommendation engines, fraud detection).
• "Amazon QLDB (Quantum Ledger Database)" - discontinued: A managed ledger database for immutable, cryptographically verifiable transaction logs. AWS ended support for QLDB on July 31, 2025, and the service is no longer available.
  • Why it still matters: For systems requiring auditable and traceable data changes (financial records, supply chain), AWS recommends "Amazon Aurora PostgreSQL" instead: trigger-populated audit (history) tables record every change to a row, and the pgAudit extension adds session and object audit logging. Unlike QLDB, this does not provide a built-in cryptographic digest.
• "Amazon Timestream": A fully managed time series database. New customers use Timestream for InfluxDB; Timestream for LiveAnalytics closed to new customers on June 20, 2025.
  • Why: For "IoT" and operational applications that need to store and analyze time-series data at scale.
• "Amazon OpenSearch Service": Managed search and analytics engine (successor to Elasticsearch).
  • Why: Full-text search with relevance scoring, log analytics and observability dashboards over semi-structured documents.
• "Amazon Keyspaces": Serverless, "Apache Cassandra"-compatible wide-column database for applications already written against Cassandra's CQL.
• Matching the data shape (quick rules):
  • Highly connected data and multi-hop traversals ("friends of friends", "people who bought what you bought") point to Neptune; modeling that with SQL joins or DynamoDB indexes gets slow and awkward.
  • Semi-structured JSON documents that must be indexed and queried natively point to DocumentDB (MongoDB-compatible); a rigid relational schema is the wrong fit.
  • Timestamped sensor/metric data queried by time range points to Timestream.
  • Transactional (OLTP: many small reads/writes) and analytical (OLAP: few complex queries over terabytes of history) workloads get different engines: Aurora/RDS for the first, Redshift for the second. Redshift is not an OLTP store and a row-oriented OLTP engine is not a warehouse. DynamoDB has no joins and is not an analytics engine.
• When a managed service is not an option: "RDS" and "Aurora" do not give you the underlying OS. "Amazon RDS Custom" offers OS and database customization but only for SQL Server for new deployments (RDS Custom for Oracle reaches end of support on March 31, 2027, and AWS recommends running those Oracle databases on EC2). If the engine or version is not offered as a managed service (a specific NoSQL engine, for example), or you need root OS access for unsupported agents on an engine such as PostgreSQL, the only viable option is to self-manage the database on EC2 and accept the patching, backup, and HA work.

Visual: AWS Database Service Options & Use Cases

⚠️ Common Pitfall: Choosing a database based on familiarity instead of the data model. For example, trying to model a highly connected social graph in a relational database, which would lead to complex, slow, and expensive recursive joins, when a graph database like "Neptune" is the purpose-built solution.

Key Trade-Offs:

• Schema Flexibility vs. Data Integrity: "NoSQL" databases (like "DynamoDB") offer flexible schemas, which is great for agile development, but relational databases (like "RDS"/"Aurora") enforce a rigid schema, which can be better for ensuring data integrity.

Reflection Question: How would you design the database solution for this social media application using a combination of "Amazon DynamoDB", "Amazon Neptune", and "Amazon Aurora PostgreSQL" with audit tables (the AWS-recommended replacement for the retired "Amazon QLDB") to meet its diverse data model (user profiles, friend connections, user actions) and consistency requirements?