This chapter covers the two most popular AWS database services: Amazon RDS (relational) and Amazon DynamoDB (NoSQL). For the CLF-C02 exam, understanding when to use each is critical because database questions appear frequently in Domain 3: Cloud Technology Services, which makes up about 32% of the exam. You will be asked to compare their use cases, consistency models, and scalability characteristics. By the end of this chapter, you will confidently differentiate RDS from DynamoDB and choose the right service for common scenarios.
Jump to a section
Imagine you run a growing business that needs to store and retrieve records. You have two options: a library with organized shelves or a giant filing cabinet. The library (Amazon RDS) is like having a team of librarians who sort every book by genre, author, and title. When you need a book, you ask the librarian, and they fetch it for you — but you must follow their rules. You can only use the library's catalog system (SQL queries) and all books must fit neatly on shelves (fixed schema). The library is great when you need to run complex searches across many books, like 'find all books about cloud computing published after 2020.' The filing cabinet (Amazon DynamoDB) is different. It's a massive set of drawers, each labeled with a simple key like 'CustomerID.' You open a drawer and pull out the folder instantly — no librarian needed. But if you want to find all customers who ordered in March, you'd have to open every drawer and check each folder unless you set up a special index (Global Secondary Index). The filing cabinet is perfect when you need fast, predictable access to individual records and can design your folders (items) to have flexible contents (schemaless). The library shines for complex queries and data integrity; the filing cabinet for speed and scale at the cost of query flexibility. In AWS, RDS is the library, DynamoDB is the filing cabinet.
Amazon RDS (Relational Database Service) is a managed service for traditional relational databases. It supports six database engines: Amazon Aurora, MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL Server. RDS automates administrative tasks like provisioning, patching, backup, and replication. You interact with it using standard SQL queries. DynamoDB is a fully managed NoSQL key-value and document database. It delivers single-digit millisecond latency at any scale. It is serverless — you don't provision servers; you provision throughput capacity (read/write capacity units) or use on-demand mode. DynamoDB uses a flexible schema: each item (row) can have different attributes (columns).
The Problem They Solve
Traditional on-premises databases require significant effort: you buy hardware, install software, configure replication, take backups, apply patches, and handle failover. RDS solves this by managing the underlying OS and database engine. You still control schema, queries, and indexes. DynamoDB solves a different problem: scaling relational databases to handle millions of requests per second is hard and expensive. DynamoDB is built for horizontal scaling from day one. It distributes data across partitions automatically, so you never need to shard manually.
How RDS Works
When you launch an RDS instance, you choose: - DB engine (e.g., MySQL) - Instance class (e.g., db.t3.medium) - Storage type (gp2/gp3, io1/io2, magnetic) - Multi-AZ (synchronous standby replica in another Availability Zone for high availability) - Backup retention period (0 to 35 days)
Under the hood, AWS creates an EC2 instance running the database engine. You connect using standard database clients (e.g., MySQL Workbench). RDS automatically handles:
Automated backups (daily snapshot + transaction logs)
Automated patching (you choose maintenance window)
Automated failover (if Multi-AZ enabled)
Storage auto-scaling (optional, up to max storage threshold)
RDS is a traditional relational database: you define tables with fixed schemas (columns, data types, constraints). You use SQL for CRUD operations and complex joins. The database enforces ACID transactions (Atomicity, Consistency, Isolation, Durability).
How DynamoDB Works
DynamoDB is schemaless. You create a table with a primary key (partition key, or partition key + sort key). Each item is a JSON-like document with attributes. You don't define columns upfront. The primary key determines how data is distributed across partitions. DynamoDB uses internal hashing: the partition key hash determines which physical partition stores the item. To read an item, you provide the primary key, and DynamoDB calculates the partition and retrieves the item in milliseconds.
DynamoDB offers two consistency models: - Eventually Consistent Reads (default): cheaper, lower latency, but might return stale data (usually within one second). - Strongly Consistent Reads: returns the most recent write, but costs more and may have higher latency.
DynamoDB scales horizontally: as throughput increases, AWS adds more partitions automatically. You can also use auto-scaling or on-demand capacity. On-demand is pay-per-request, suitable for unpredictable workloads.
Key Features Comparison
Query Flexibility: RDS supports complex SQL queries with joins, aggregations, subqueries. DynamoDB supports queries on primary key and secondary indexes; joins are not supported — you must denormalize or use application-side joins.
Indexes: RDS uses B-tree indexes; you can create multiple indexes per table. DynamoDB supports Local Secondary Indexes (LSI) and Global Secondary Indexes (GSI). GSIs are flexible but eventually consistent.
Transactions: RDS supports full ACID transactions. DynamoDB supports ACID transactions across multiple items within a single AWS account and region (since 2018). However, DynamoDB transactions are more limited in scope and have higher latency.
Scalability: RDS scales vertically (larger instance) and read replicas (up to 15 for some engines). DynamoDB scales horizontally automatically — no limit on table size.
Pricing: RDS: pay per hour for instance + storage + I/O. DynamoDB: pay per read/write capacity unit (provisioned) or per request (on-demand) + storage.
When to Use RDS vs DynamoDB
Use RDS when:
Your data requires complex relationships (e.g., e-commerce orders with customers, products, payments).
You need ACID transactions with full SQL support.
You have existing applications built on relational databases.
You need fine-grained access control at row/column level (via database users).
Use DynamoDB when:
You need single-digit millisecond latency at any scale.
Your workload is read/write heavy with simple access patterns (key-value lookups).
You have unpredictable traffic (on-demand mode).
You want a serverless database with no maintenance (no patching, no backups to manage — though DynamoDB does continuous backups automatically).
Your data is schemaless or changes frequently.
Pricing Models in Detail
RDS Pricing: - On-Demand: Pay by the hour for the instance class (e.g., db.t3.micro ~$0.017/hr). - Reserved Instances: 1- or 3-year term, up to 60% discount. - Storage: $0.08/GB-month for gp2, $0.005/GB-month for magnetic (but low performance). - I/O: Only for magnetic storage; gp2/gp3 include baseline I/O. - Backup: Automated backups consume storage at $0.095/GB-month (first 100% of DB size free).
DynamoDB Pricing: - Provisioned Mode: You specify Read Capacity Units (RCU) and Write Capacity Units (WCU). 1 RCU = 1 strongly consistent read of 4KB/s or 2 eventually consistent reads. 1 WCU = 1 write of 1KB/s. Price: ~$0.0013 per RCU-hour, $0.00065 per WCU-hour. - On-Demand Mode: Pay per request: $1.25 per million write request units, $0.25 per million read request units. - Storage: $0.25 per GB-month. - Backups: Continuous backups (point-in-time recovery) cost additional storage.
Comparison to On-Premises
Running a relational database on-premises means buying servers, storage, networking, and hiring DBAs. RDS eliminates this but still requires schema design and query optimization. DynamoDB has no on-premises equivalent — it's a cloud-native distributed database. If you try to run a NoSQL database on-premises, you must manage clusters, replication, and sharding. DynamoDB abstracts all that.
Launch an RDS MySQL Instance
Log into AWS Console, navigate to RDS, click 'Create database'. Select 'Standard create', engine: MySQL, version 8.0. Choose a template: 'Free tier' (db.t2.micro, 20GB storage). Under Settings, set DB instance identifier (e.g., 'mydb'), master username and password. Under DB instance size, select burstable class db.t3.micro. Under Storage, enable storage autoscaling with max 100GB. Under Connectivity, choose default VPC, public access 'No' (for security). Under Additional configuration, set initial database name 'mydatabase', backup retention 7 days, enable automated backups, maintenance window default. Click 'Create database'. AWS provisions an EC2 instance with MySQL, applies security group rules, and creates the database. You'll receive an endpoint (DNS name) to connect via MySQL client.
Connect and Create a Table
Install MySQL Workbench or use mysql CLI. Connect using the endpoint, port 3306, username, and password from step 1. Run: `CREATE TABLE customers (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100), email VARCHAR(100));` This creates a relational table with fixed columns. You can then insert data: `INSERT INTO customers (name, email) VALUES ('Alice', 'alice@example.com');` RDS handles storage, replication (if Multi-AZ), and backups. All SQL operations are standard.
Create a DynamoDB Table
Navigate to DynamoDB console, click 'Create table'. Enter table name 'Customers'. For Partition key, enter 'CustomerID' as Number (or String). Optionally add Sort key 'OrderDate' (String). Leave default settings: 'Default settings' uses provisioned capacity with auto-scaling, 5 RCU and 5 WCU. Click 'Create'. DynamoDB creates the table immediately — no instance provisioning. You can now add items: click 'Explore items', then 'Create item'. Enter JSON: { "CustomerID": 1, "Name": "Alice", "Email": "alice@example.com", "Orders": [{"OrderID": 101, "Date": "2024-01-15"}] }. Notice the schema is flexible: different items can have different attributes. DynamoDB automatically partitions data based on CustomerID hash.
Query DynamoDB vs RDS
In DynamoDB, to get a customer by ID, use: `aws dynamodb get-item --table-name Customers --key '{"CustomerID": {"N": "1"}}'` (CLI). This is a key-value lookup — extremely fast. To get all customers with orders after a date, you need a Global Secondary Index on OrderDate. In RDS, you can run: `SELECT * FROM customers JOIN orders ON customers.id = orders.customer_id WHERE orders.date > '2024-01-01';` This complex join is not possible in DynamoDB without application logic. DynamoDB queries are limited to primary key and index lookups.
Scale and Manage
For RDS scaling: modify instance class (vertical scaling) — takes minutes, may cause downtime. Add read replicas (horizontal scaling for reads) — up to 5 for MySQL, 15 for Aurora. For DynamoDB scaling: increase provisioned RCU/WCU via console or auto-scaling — changes take effect in minutes. Or switch to on-demand mode for unlimited throughput. DynamoDB scales horizontally automatically — no sharding needed. RDS Multi-AZ provides high availability via synchronous standby; DynamoDB stores three copies of data across an AWS Region automatically (within same region, across multiple AZs).
Scenario 1: E-Commerce Platform A mid-sized online retailer uses RDS PostgreSQL for its transactional database. Customer orders, payments, and inventory are relational: an order links to customer, products, and shipping address. They need ACID transactions to ensure that when a payment is processed, inventory is decremented atomically. RDS Multi-AZ provides failover during maintenance. They also use read replicas for reporting queries. Cost: ~$500/month for a db.r5.large instance with 500GB gp3 storage. Misconfiguration: they initially used magnetic storage, causing slow queries. They switched to gp3 and saw 10x performance.
Scenario 2: Gaming Leaderboard A mobile game company uses DynamoDB for player scores and leaderboards. Each player's score is stored with partition key = PlayerID, sort key = ScoreTimestamp. They query top scores using a Global Secondary Index on Score. DynamoDB handles millions of concurrent writes during tournaments. They use on-demand mode to avoid provisioning for spikes. Cost: ~$0.30 per million writes, $0.15 per million reads. Misunderstanding: they tried to use DynamoDB for complex queries like 'find all players who purchased an item in the last week' — but DynamoDB cannot do that efficiently without scanning. They added a separate RDS instance for analytics.
Scenario 3: IoT Sensor Data A smart agriculture startup ingests temperature and humidity data from thousands of sensors every minute. They choose DynamoDB because of its high write throughput and serverless nature. Each sensor writes a record with SensorID (partition key) and Timestamp (sort key). They use time-to-live (TTL) to automatically delete data older than 30 days. They query recent data per sensor using the sort key. Cost: ~$100/month for provisioned 1000 WCU and 500 RCU. Problem: they initially set RCU too low, causing throttling. They enabled auto-scaling with a minimum of 500 RCU.
Exam Objective 3.3: Determine which AWS service is appropriate for a given use case (specifically comparing RDS and DynamoDB). This objective appears in Domain 3: Cloud Technology Services (~32% of exam). Expect 2-4 questions directly comparing RDS and DynamoDB.
Common Wrong Answers: 1. 'DynamoDB supports SQL queries' — No, DynamoDB uses a proprietary API (PartiQL is SQL-compatible but limited). The exam tests that DynamoDB is NoSQL, not relational. 2. 'RDS is serverless' — RDS is managed but not serverless; you provision instances. Aurora Serverless is serverless, but standard RDS is not. 3. 'DynamoDB is cheaper for all workloads' — For complex relational queries, RDS is cheaper because DynamoDB would require scanning and application logic. 4. 'RDS scales horizontally automatically' — RDS scales vertically; horizontal scaling requires read replicas (for reads) or sharding (application-level).
Tricky Distinctions: - ACID: Both support ACID, but RDS is fully ACID; DynamoDB transactions are limited and have higher latency. - Latency: DynamoDB guarantees single-digit millisecond latency; RDS latency varies by query complexity and instance size. - Schema: RDS requires fixed schema; DynamoDB is schemaless. - Scaling: DynamoDB scales horizontally automatically; RDS scales vertically or via read replicas.
Decision Rule for Exam Questions: If the scenario mentions:
Complex queries, joins, or reporting → RDS
Key-value lookups, high throughput, low latency, serverless → DynamoDB
Unpredictable traffic → DynamoDB (on-demand)
Existing SQL application → RDS
Need for fine-grained access control at row level → RDS
Need for flexible schema → DynamoDB
Eliminate options that conflict with these patterns.
RDS is for relational data requiring complex queries, joins, and ACID transactions; DynamoDB is for key-value lookups with low latency at any scale.
DynamoDB is schemaless; RDS requires a predefined schema.
RDS scales vertically and via read replicas; DynamoDB scales horizontally automatically.
DynamoDB offers two consistency models: eventually consistent (default, cheaper) and strongly consistent.
RDS Multi-AZ provides high availability with a synchronous standby in another AZ; DynamoDB stores three copies across AZs automatically.
DynamoDB on-demand mode is ideal for unpredictable workloads; provisioned mode requires capacity planning.
RDS supports six database engines: Amazon Aurora, MySQL, MariaDB, PostgreSQL, Oracle, SQL Server.
These come up on the exam all the time. Here's how to tell them apart.
Amazon RDS
Relational database with fixed schema (tables, columns, data types).
Supports complex SQL queries, joins, aggregations, and subqueries.
Scales vertically (larger instances) and horizontally via read replicas (up to 15).
Priced by instance hour + storage + I/O; reserved instances available.
Fully ACID compliant with traditional transaction support.
Amazon DynamoDB
NoSQL key-value and document database with flexible schema.
Queries limited to primary key and secondary index lookups; no joins.
Scales horizontally automatically; no practical limit on table size.
Priced by read/write capacity units (provisioned) or per request (on-demand) + storage.
Supports ACID transactions but with higher latency and limited scope.
Mistake
DynamoDB cannot handle transactions at all.
Correct
DynamoDB supports ACID transactions across multiple items within a single account and region since 2018, but they are more limited and have higher latency than RDS transactions.
Mistake
RDS is serverless, so you don't need to manage any capacity.
Correct
Standard RDS requires you to choose an instance type and storage size. Only Aurora Serverless (v2) is serverless, but it's still a separate feature.
Mistake
DynamoDB is always cheaper than RDS.
Correct
For workloads with complex queries and low traffic, RDS can be cheaper. DynamoDB charges per request, which can be expensive for large scans or infrequent access patterns.
Mistake
You can run SQL queries directly on DynamoDB tables.
Correct
DynamoDB supports PartiQL, a SQL-compatible query language, but it is limited to operations that map to DynamoDB's API (e.g., SELECT with WHERE on key/GSI). Complex joins are not supported.
Mistake
RDS Multi-AZ automatically scales read capacity.
Correct
Multi-AZ provides high availability via a standby replica in another AZ, but that standby is not used for reads. To scale reads, you must create separate read replicas.
DynamoDB supports PartiQL, a SQL-compatible query language, but it is not full SQL. You can run SELECT, INSERT, UPDATE, and DELETE statements, but they are limited to operations that map to DynamoDB's API (e.g., you must specify the primary key in WHERE clauses for efficient queries). Complex joins, subqueries, and aggregations are not supported. For the exam, remember that DynamoDB is NoSQL and does not support standard SQL.
DynamoDB guarantees single-digit millisecond latency for key-value lookups at any scale. RDS latency depends on query complexity, instance size, and load. For simple key-value reads, DynamoDB is faster. For complex queries, RDS may be faster because DynamoDB would require multiple API calls or scans. On the exam, if the question emphasizes low latency for simple lookups, choose DynamoDB.
RDS supports storage auto-scaling (increases storage automatically when nearing capacity) and read replicas (for read scaling). However, compute scaling (changing instance class) is manual and may cause downtime. DynamoDB auto-scales throughput automatically when enabled. For the exam, know that RDS does not automatically scale compute; DynamoDB can auto-scale throughput.
Standard RDS is not serverless because you must provision an instance. However, Amazon Aurora Serverless v2 is a serverless relational database compatible with MySQL and PostgreSQL. It automatically scales compute and memory. For the exam, note that 'RDS' typically refers to provisioned instances unless specified as 'Aurora Serverless'.
Migrating from RDS to DynamoDB requires redesigning your data model. You must denormalize your relational schema into key-value or document format. Use AWS Database Migration Service (DMS) for initial load and ongoing replication, but DMS may not handle schema conversion automatically. For the exam, know that moving from RDS to DynamoDB is a significant architectural change, not a simple lift-and-shift.
Eventually consistent reads (default) are cheaper and have lower latency but may return stale data (usually within one second). Strongly consistent reads return the most recent write but cost more and may have higher latency. Use strongly consistent reads when you must read immediately after a write (e.g., leaderboard after a score update). The exam tests that DynamoDB offers these two consistency models.
No, DynamoDB is a NoSQL database. It does not support relationships (foreign keys), joins, or complex queries. If you need relational features, use RDS. You could model relational data in DynamoDB using denormalization and application-side joins, but it is not recommended for complex relationships.
You've just covered RDS vs DynamoDB — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?