---
name: choose-a-database
description: 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.
license: Apache-2.0
metadata:
  source: agent-toolkit-for-aws
---

# 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

1. **Data model** — relational (joins, transactions), key-value, document,
   graph (relationships-as-first-class), time-series, or wide-column?
2. **Access pattern** — a few well-known query shapes, or ad-hoc/analytical
   queries? Read-heavy, write-heavy, or spiky?
3. **Scale and latency** — request rate, item size, dataset size, and the
   latency target (single-digit ms?).
4. **Consistency** — strong vs eventual; multi-region active-active needs?
5. **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).