RDS vs DynamoDB

WHAT IS BEING DECIDED The primary datastore: a managed relational database, or a managed key-value and document store. This is among the hardest decisions to reverse in an application, because the data model and much of the query code follow from it. The useful framing is not SQL versus NoSQL. It is whether your access patterns are known and stable enough to design a schema around them up front. HOW TO WEIGH IT Weight query flexibility heavily if the product is young and the access patterns are still being discovered — relational gives you the ability to ask questions you have not thought of yet, and early products ask a lot of those. Weight predictable scale heavily if you have a known, high-volume, simple-key workload where single-digit-millisecond latency at any size is a requirement. Weight team familiarity honestly. A well-modelled relational schema operated by people who understand it beats a poorly modelled key-value schema in almost every case. WHEN EACH WINS RDS wins for the general case: transactions across entities, joins, aggregate reporting, and the freedom to add an index when a new question arrives. Most applications are this. DynamoDB wins when access is dominated by key lookups at scale, when you want capacity that grows without a resize, or when operational simplicity matters more than query expressiveness. It punishes unanticipated access patterns — retrofitting a new query shape often means a new index or a migration of the data model itself. HOW TO DECIDE Write down your top ten queries before choosing. If you can enumerate them confidently and they are key-based, DynamoDB is a strong fit. If the list is uncertain, or contains aggregates and ad-hoc filters, choose relational. The cost of a relational database you outgrow is a scaling project; the cost of a key-value model that does not match your queries is a rewrite. See /dataops and record the decision with the template at /templates.