What this prompt does
This prompt has the AI produce a defensible RDS-versus-DynamoDB decision for [application_type] with [data_characteristics] and [access_patterns]. It models [entity_name] in both an [rds_engine] relational schema and a DynamoDB single-table design, shows how each handles [complex_queries], compares performance at [current_scale] and projected [future_scale], estimates monthly cost for [workload_profile] in each, weighs operational overhead, evaluates a hybrid split, assesses migration difficulty, and ends with a clear recommendation.
The structure works because it forces the comparison people usually skip: modeling the same entity both ways and pricing each at projected scale. Implementing [complex_queries] in each database surfaces where DynamoDB's access-pattern-first design either fits naturally or fights you. The explicit recommendation with reasoning turns a vibe-based argument into a decision a team can review. Feeding in your real [data_characteristics] — for instance highly relational product data sitting next to simple key-value cart data — is what lets the model spot when neither database alone is the right answer.
When to use it
- A team is torn between relational and NoSQL and wants a reasoned decision rather than a preference.
- You need to see
[entity_name]modeled in both[rds_engine]and DynamoDB single-table form side by side. - You have
[complex_queries]like aggregations or joins and want to know which database handles them naturally. - You want a cost comparison for
[workload_profile]at both current and projected scale. - You suspect a hybrid split (some data in RDS, some in DynamoDB) and want it evaluated honestly.
- You want to understand how hard a later migration between the two would be before committing.
Example output
Expect a comparison document: the same [entity_name] modeled relationally and as DynamoDB single-table with trade-offs called out, side-by-side implementations of [complex_queries], a scale analysis at [current_scale] and [future_scale] with capacity planning, a monthly cost estimate for [workload_profile] in each service, an operational-overhead comparison, a hybrid-split proposal with a sync strategy, a migration-difficulty assessment, and a final recommendation with reasoning.
Pro tips
- List every entry in
[access_patterns]precisely; DynamoDB's fit is judged entirely against access patterns, and a missing one can flip the recommendation. - Pay close attention to how
[complex_queries]map — aggregations and ad-hoc joins are where relational often wins and DynamoDB needs workarounds. - Price
[workload_profile]at[future_scale], not just today; DynamoDB and RDS cost curves diverge as load grows, and the cheaper option can swap. - Take the hybrid split seriously — relational product data with key-value cart/session data is a common case where neither database alone is best.
- Weigh operational overhead honestly: DynamoDB removes patching and scaling chores, while
[rds_engine]gives you richer querying at the cost of more management. - Treat the migration-difficulty section as real risk assessment; the data model, not the data volume, is what makes a later switch hard.
- Sanity-check the recommendation against your team's operational comfort; the technically optimal database is the wrong pick if nobody on the team can run
[rds_engine]or model single-table DynamoDB confidently.
