A city's 311 resident-facing chatbot needs to persist conversation session state, keyed by session ID, that will later be reused as fine-tuning data. The team is deciding between Amazon DynamoDB and Amazon RDS for this store, given that access is almost entirely single-item reads and writes by session key with no complex joins. Which choice fits this access pattern?
Select an answer to reveal the explanation.
Short Explanation
Think of DynamoDB like a coat check — you hand over a ticket (the session ID), and it hands back exactly the right item, fast, with no need to page through a filing cabinet of unrelated records. That's exactly the read/write pattern here: single-item access by session key, no joins. DynamoDB fits that shape naturally, while a relational schema would add structure this workload doesn't actually use.
Full Explanation
DynamoDB's key-value model is built for exactly this access pattern — single-item reads and writes addressed by a primary key — and it scales that pattern horizontally without the schema migrations or query planning overhead a relational engine carries for workloads that never need joins. Claiming RDS handles single-key lookups just as efficiently sidesteps that a relational engine still pays for transaction management, index maintenance, and query planning designed for relational access, none of which this workload uses. Claiming a relational schema is necessary before conversation data can be used for fine-tuning confuses storage structure with training-data preparation — fine-tuning data gets extracted, formatted into prompt-response pairs, and validated as a separate step regardless of whether the source store was relational or key-value. Saying DynamoDB removes the need to think about schema design overstates its flexibility: DynamoDB still requires deliberate key design (partition and sort keys) to avoid hot partitions and support the access patterns the application actually needs, even without a rigid relational schema. Scope note: if session data later needs complex ad hoc querying across many attributes, that's a signal to reconsider the store, not a reason to default to DynamoDB blindly. Operational check: review the DynamoDB partition key design against expected session ID distribution to rule out hot-partition risk before launch.