A reporting team needs to run ad hoc SQL queries that join a customer table with an orders table and aggregate totals by region, and the schema and relationships are expected to evolve as new reports are requested. Which database is the more natural fit for this workload?
- DynamoDB, because it scales writes better under any workload
- Amazon RDS, because its relational engine supports ad hoc SQL joins and aggregations across normalized tables
- DynamoDB, because global secondary indexes can replace SQL joins for any query pattern
- Amazon RDS, but only if DynamoDB Accelerator (DAX) is attached to it
Why B? And why not the others?
Correct answer: B. Amazon RDS, because its relational engine supports ad hoc SQL joins and aggregations across normalized tables
Relational engines like those behind Amazon RDS are built around SQL, normalized schemas, and a query optimizer capable of executing arbitrary joins and aggregations across tables, which is exactly what ad hoc, evolving reporting queries with joins and group-by aggregation require; DynamoDB, by contrast, requires access patterns to be designed in advance around specific partition and sort keys and does not support general-purpose joins. The option favoring DynamoDB for write scaling is wrong because the question is about flexible ad hoc querying, not raw write throughput, and superior write scaling does not help a workload that needs SQL joins. The option describing global secondary indexes as a substitute for joins is wrong because they only support querying an item collection by an alternate key, not combining rows from two different tables the way a relational join does, so they cannot generally replace SQL joins for arbitrary reporting needs. The option requiring DAX is wrong because DAX is a caching layer for DynamoDB reads and is unrelated to RDS; it is not a prerequisite for RDS supporting SQL joins, which it already does natively.
Source: AWS documentation: choosing between DynamoDB and relational databases (RDS)