Exercise 3: Why DynamoDB Is a Poor Fit for Complex, Changing Reports — Possible Solution ==================================================================== DynamoDB's own real data model is built around fast, predictable lookups by a known partition key (optionally with a sort key) -- it has no real join capability across tables the way a relational database does. Any query pattern not anticipated at table-design time (which partition/sort key structure will actually be queried) tends to require either an expensive full scan, or a redesign of the table's own key structure to support the new access pattern. The scenario described has two real, compounding problems for DynamoDB specifically: complex, ad-hoc SQL-style reports genuinely need to join data across many related tables, which DynamoDB doesn't support natively at all; and access patterns that will likely CHANGE over time mean whatever key structure is chosen up front may stop fitting the real queries the team actually needs later, requiring disruptive rework. ANSWER: DynamoDB would be a poor fit here because its own real strength -- fast, predictable lookups by a known key -- is precisely what this scenario doesn't need, while its own real weakness -- no native joins, and key structures that are hard to change later -- directly conflicts with both stated requirements (complex joined reporting, and evolving access patterns). RDS's own relational model, supporting real ad-hoc SQL joins and flexible querying without needing every access pattern anticipated in advance, is the genuinely better fit for this specific scenario. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly identifies that DynamoDB CAN technically store the data (as the question itself notes) but explains why storing it isn't the same as being able to QUERY it the way this scenario needs -- directly applying the chapter's own comparison table's "query flexibility" and "best real fit" rows to a concrete case, rather than just restating that RDS is "for relational data."