choose-a-database
Decision guide for choosing the right AWS database service for a workload. Use when the user is unsure which database to use, is comparing options, or asks whether to use DynamoDB, Aurora, RDS, DocumentDB, ElastiCache, MemoryDB, Neptune, Keyspaces, or Timestream. Walks through access patterns, data model, consistency, scale, and cost tradeoffs across relational, key-value, document, wide-column, graph, time-series, and in-memory engines, and recommends a fit with rationale and Well-Architected considerations.
94%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Choose an AWS database
Recommend a database by matching the workload's access pattern and data model to an engine — not by defaulting to what is familiar. Ask for anything missing before recommending.
Questions to resolve first
- Data model — relational (joins, transactions), key-value, document, graph (relationships-as-first-class), time-series, or wide-column?
- Access pattern — a few well-known query shapes, or ad-hoc/analytical queries? Read-heavy, write-heavy, or spiky?
- Scale and latency — request rate, item size, dataset size, and the latency target (single-digit ms?).
- Consistency — strong vs eventual; multi-region active-active needs?
- Operational model — fully managed/serverless preferred, or is a provisioned instance acceptable? What is the cost floor tolerance?
Fit guide
| If the workload is... | Prefer | Why |
|---|---|---|
| Known access patterns, massive scale, single-digit ms, serverless | DynamoDB | Scale-to-zero on-demand, no servers, predictable latency. Model for access patterns, not normalization. |
| Relational with joins/transactions, PostgreSQL/MySQL compatible | Aurora | Managed, high-throughput, replicas; Aurora Serverless v2 scales capacity automatically. |
| Relational, needs a specific engine (Oracle, SQL Server, MariaDB, Db2) | Amazon RDS | Managed instances of the engine you require. |
| Relational, spiky/intermittent, want true scale-to-zero SQL | Aurora DSQL | Serverless distributed SQL, active-active, no instance floor. |
| JSON documents, MongoDB API | DocumentDB | Managed document store with MongoDB compatibility. |
| Sub-ms cache or ephemeral session/leaderboard data | ElastiCache (Redis/Valkey/Memcached) | In-memory cache; data is not durable by default. |
| In-memory but needs durability | MemoryDB | Redis-compatible, durable, multi-AZ. |
| Highly connected data, relationship traversal | Neptune | Purpose-built graph (property graph + RDF/SPARQL). |
| Wide-column, Cassandra API | Keyspaces | Serverless Cassandra-compatible. |
| Metrics/events over time, time-window queries | Timestream | Purpose-built time-series with tiered storage. |
Boundaries to call out
- Relational needs a relational engine. Do not mangle a schema with joins and transactions into a key-value store. If the user wants scale-to-zero cost but has relational needs, point them to Aurora Serverless v2 or Aurora DSQL.
- Cost floor. RDS/Aurora provisioned instances bill even when idle; DynamoDB on-demand, Aurora DSQL, and Keyspaces are the scale-to-zero options.
- Verify limits. Confirm quotas, item/row size limits, and regional availability against live documentation before committing.
Output
State the recommended service, the one or two runner-up options, and why — tied to the access pattern and the Well-Architected cost and reliability pillars. Then offer to scaffold it as infrastructure-as-code (CDK or CloudFormation).
- Revision
c5551e1
- Last updated
- First committed
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.